Re: Tor speed

[Drake Wilson <drake@xxxxxxxxxxxx>]

(This message has one Bcc recipient.)

Quoth slush <slush@xxxxxxxx>, on 2009-02-13 09:55:45 +0100:
> But what in the case of short-time overloading? My tip is, that in
> this case, node is working for somebody faster than for else. I
> think so, because it can be the reason, why I often have ZERO
> throughput thru Tor for tens seconds.

One case that has probably been discussed before (but not in this
thread) is that TCP isn't really good for overlay networks that pass
many concurrent streams.  TCP enforces in-order delivery of all the
packets on a connection between two onion routers, when in fact in the
ideal case, this ordering is not required, and only ordering within
streams is necessary.  Enforcing full in-order delivery across streams
magnifies the effects of latency and packet loss, and can cause data
rate allocation between streams to be suboptimal; it's literally true
that while one stream is tying up the TCP connection, another cannot
use it at all, even though the streams are effectively preempted after
transferring a certain number of bits in a slice/cell so that the
delay does not become unbounded.  (It's rather like pre-emptive
scheduling of multiple tasks on a uniprocessor computer, in fact.)

(Theoretically there's going to be enforced-ordering lossage somewhere
anyway, because the physical world forces this to some extent, but a
TCP connection has much more of this than would be present if one were
using the underlying packet network more directly, I think.)

Using a protocol like SCTP might help with this, but that brings up
various other annoying practical problems that are particularly
annoying because there's no good reason for them to exist.

> Thanks,
> Marek

   ---> Drake Wilson