[tor-talk] IDEA: Compress traffic at exit

[Sebastian G. <bastik.tor>]

Am 21.01.2012 15:39, schrieb proper at tormail.net:

> I see three different ways to compress traffic. 1), 2) and 2) They could
> be all implemented alone or all in combination.
> 
> 1) website compression
> Long time ago I tested services like traffic compressor (a free legitimate
> public proxy). It really enhanced the speed, especially websites with lots
> of high quality pictures.

According to Andrew Lewmann lot's of stuff is already compressed. He
also says, bandwidth isn't the problem, CPU is the critical resource.

> The exit server would hook into all outgoing unencrypted http connections
> and compress the website using a similar mechanism like services like
> traffic compressor. An option to opt-out or opt-in this feature for the
> exit and the Tor-user would be needed as well.

That would add CPU load to the exit, which hurts the network because the
exit can't handle that much onion-skins.

> 2) caching proxy
> Just like existing caching proxys. The exit server would safe bandwidth if
> they wouldn't always request all websites fresh but use a local cache.
> Also option for both, Tor-user and exit server if they wish to use the
> feature.

That could indeed save bandwidth, but only for popular sites. The cache
would have to be refreshed from time to time. Also this would require
space for the cached files. I'm sure that this would work.

This has nothing to do with compression IMO, just saving bandwidth.

You could post it as separate idea.

Keep in mind that the torproject knows it's requirements and that
bandwidth doesn't seem to be the problem.

I'm not sure if that would be used. When I'd use Tor for anonymity I
wouldn't want something to store anything on my behalf. ON the other
hand, when the website doesn't need to be fetched from it's original
server it might be harder to monitor for an adversary.

> 3) connection compression
>>From Tor-user to exit server.
> - it would put more cpu load on the Tor-user, but he could get an option
> if wants to use compression or not

Yes, in my case the user requested compression if he could handle the
decompression, the sever could opt in or out.

> - it would put more cpu load on the exit node as it would have to
> uncompres the date before sending it to the target server

The problem is that it causes that extra CPU load the exit can't afford.

> - therefore also the exit nodes could get an option if they accept
> compressed connections or not, if they want to safe cpu load

That's included in mine as well, but the majority of exit are already
overloaded, so they would have to opt out, which makes compression
requests useless, because those won't be honored.


> - this method of compression would put less load on the entry and middle
> nodes

That was what I had in mind, but to quote Andrew:
"What tor does in the middle is irrelevant." (in terms of compression,
because it's already compressed)

Regards,
bastik_tor