Proposal: Speed up Tor

Thu Jun 14 20:44:38 UTC 2007

I'm not a developer of Tor, but I like your idea about the possibility
to split up downloads into different circuits. And separating downloads
from other more important circuits. I like the idea. But in some cases,
the server where the downloaded zip/exe-file is stored, doesn't allow
splitted downloads. And in some other cases, the download source doesn't
allow another ip than the one you used during authentication/login.

If such a method would be programmed, it would also be good for the
tor-servers to be able to choose how high percentage of their bandwidth
should go to low-priority traffic like downloads, P2P, etc.
Because the communication is encrypted, there has to be two new "flags"
for the servers, and for the packets sent. Otherwise it wouldn't be
possible to separate low priority and high priority traffic.
Either these server-flags could be set by the server admin, or by the
tor-software based on server speed, and based on the port number the
server uses. If the server uses a very uncommon server port, that server
should concentrate on beeing an entry server, allowing traffic from
clients that can't connect to the common ports 9030, 9031, 80 and 443.
(See my suggestion about improving accessibility of Tor by allowing more
entry ports)
And if the traffic is encrypted from end to end, for example with SSL,
it wouldn't be possible for Tor clients and servers to distinguish
what's in the traffic. So then it's not possible to mark pakets as
low-priority.

Two things that slow down the Tor network are that DNS-requests are done
through the network (terribly slow?), and that some exit servers are
unresponsive (and/or block certain IP without configuring the blocked
ports in torrc).
The new tor 0.2.0.2alpha makes the network faster for combined servers
and clients with the new relay-settings.

Tor-developpers, if you read this, is there any spec. about all the
flags that every packet sent through tor can have? Are these packet
flags also encrypted between servers, or do they just have a crc?

/Viking

Michael_google gmail_Gersten wrote:
> I would like to know what is the next step to take to make this
> happen. According to the tor design document I read, the procedure for
> making changes to Tor is to first write up a proposal, then have it
> discussed on the developer list, and then when it's well-understood,
> code it. Yet there's no discussion, no feedback. What should I do
> next?
>
> On 6/1/07, Michael_google gmail_Gersten <keybounce at gmail.com> wrote:
>> Proposal for Tor.
>>
>> The goal of this proposal is to support the following goals:
>>
>> 1. An easy way to toggle between "At least speed X" (for
>> single-threaded web browsing) and "Any speed, many connections" (for
>> downloads).
>> 2. A way to keep nodes from being CPU starved from the encryption
>> processing (high bandwidth nodes)
>> 3. A way to keep nodes from being bandwidth starved (the main limit on
>> middle-speed nodes).
>>
>> Motivation: Speed up Tor.
>>
>> Design:
>> 1. Add in a control message for switching torrc's. Add support in
>> Vidiallia to toggle these.
>>         Flaw: Ideally the determination (high speed vs. high numbers)
>> would
>> be made based on who is making the request. For example, while the
>> downloader is fetching 10 slow parts at once, I still want to browse.
>>
>> 2. If the protocol for extending a circuit to a new node does not
>> permit the new node to reject the connection, then add this ability.
>> Otherwise, start using it. Nodes can prevent being CPU starved by
>> refusing new connections when they are "full".
>>
>> 3. When a circuit is being built, estimates of bandwidth needed are
>> transmitted as well. Similar to #2, nodes will reject new connections
>> if the bandwidth isn't there.
>>
>> Security implications: Absolutely no idea. How does having large
>> numbers of connections affect Tor's tracability?
>>
>> Specification (incomplete):
>> 1. New control message would either take a filename of the new torrc,
>> or the contents of the new torrc. I do not know Tor's inner workings,
>> and cannot tell which is "better".
>>
>> 2. Nodes can measure the CPU cost per circuit, and tell how many they
>> can afford CPU wise. There may be a configuration parameter to
>> indicate how much CPU it can use; maybe the output of "uptime" is read
>> to see what the CPU levels are (and Tor stops accepting when the load
>> is .8 or higher.)
>>
>> 3. The simplest way to handle this is to put numbers in the config
>> file, and pass them along. For example, if I'm in "single threaded
>> browsing", I'll have numbers specifying a max speed of 150 KB/s, a
>> burst speed of 100 KB/s, and an average speed of 10 KB/s. If I'm in
>> "multi-threaded download", I'll specify a max speed of 25 KB, an
>> average speed of 15 KB, and a burst speed of 18 KB.
>>
>> What to do with these numbers? Well, if the sum of the averages of all
>> incoming circuits exceed my actual bandwidth, I say "No" when someone
>> tries to connect. Similarly, if I cannot support the burst speed, I
>> saw "No", to avoid slowing them down (this becomes the minimum speed
>> needed). Finally, I know that the worst case for this circuit is the
>> max speed, and I can do ... ? with it.
>>
>> The idea here: On my DSL, I cannot get more than 150 KB/s. While I
>> want to get that full speed, I'll be happy to get 100 KB/s. On
>> average, while I'm surfing, I'm not fetching pages all the time --
>> hence, an average speed of 10 KB/s representing fetch, read, fetch,
>> read, fetch, read.
>>
>> Now, it's not perfect. I'm thinking that "Busy percentage" might make
>> more sense -- 10% busy for web surfing, 95% busy for downloaders. This
>> would also help CPU overhead calculations. It also helps tell when to
>> say "This circuit has been idle for a while. It isn't active at all,
>> and while it is inactive, we will regard it as having a speed demand
>> of 0". This will prevent a node from being filled up with "idle"
>> connections, and becoming wasted.
>>
>> I'm also realizing that my concept of "burst" isn't quite right, and
>> I'm hoping that someone else has a better idea. For downloading,
>> "burst" means that while the average demand for a 10 part download is
>> 15 KB/s per circuit, there will be variance, and a node might see a
>> higher burst. Yet I will be happy even if a node can only give me 10
>> KB/s, because I have 9 other circuits that will each get slightly more
>> speed. So I think we need "This is my minimum acceptable speed, reject
>> this circuit if you can't give me this much", "This is my average",
>> and "This is my worst case / initial burst" (a lot of circuits will be
>> busy at first, and idle afterwards), as well as "percentage of time I
>> expect the circuit to be used".
>>
>> Compatibility: The only change in how nodes talk to each other is in
>> circuit building. I am not familiar with the current system to know
>> how this will change things.
>>
>