Re: [tor-talk] IDEA: Compress traffic at exit

[proper@xxxxxxxxxxx]

> Hi, it's me again.
>
> I got another idea.
>
> I don't understand what works and what has to be done exactly. I'm not
> an developer. I don't understand the technical background as well as
> needed to predict my changes to the specs.
>
> It's written in the form of a proposal, but it should not be treated as
> such. I just used this from to have something that helps to make it
> cleaner compared to free form. It's an idea.
>
> I started writing it down yesterday.
>
> Below I've pasted the Overview and Motivation. The full version is
> attached.
>
> Overview:
>
>    This is about compressing traffic at the exit, where it's passed from
>    outside the network through other relays to the client where it
>    gets decompressed.
>
>    The compression should happen on the fly.
>
>    This is NOT about which compression is actually used.
>
>    It's an idea. It outlines what has to be done, but not how.
>
> Motivation:
>
>    The network has a high bandwidth usage due to it massive user-base.
>    This idea should reduce the outgoing traffic of the exit and take
>    much load from the mid-relay and the entry point.
>
>    The relays (exit or not) have certain bandwidth limitations which may
>    could be circumvented by compressing the traffic they have to handle,
>    which would mean that they could handle more users.
>
>    The main motivation is to improve the performance of the network,
>    e.g. to serve more users and remove bottlenecks.
>
> Regards,
> bastik_tor
>
> ps.: there's nothing piled up, no ideas left to tell you, yet.
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>

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.

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.

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.

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
- 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
- therefore also the exit nodes could get an option if they accept
compressed connections or not, if they want to safe cpu load
- a research would be needed if that compression would weaken encryption
(but normally with good encryption it shouldn't matter what they encrypt,
even public known things should be fine)
- this method of compression would put less load on the entry and middle
nodes
- the exit nodes would have to decompress and to forward the traffic as
usual, so they wouldn't safe bandwidth

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk