[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Tor speed

To: or-talk@xxxxxxxxxxxxx
Subject: Re: Tor speed
From: "F. Fox" <kitsune.or@xxxxxxxxx>
Date: Fri, 13 Feb 2009 05:56:35 -0800
Delivered-to: archiver@xxxxxxxx
Delivered-to: or-talk-outgoing@xxxxxxxx
Delivered-to: or-talk@xxxxxxxx
Delivery-date: Fri, 13 Feb 2009 08:56:42 -0500
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=WOQnmRC4VcsTQ4Tp9q1Ez9Mc+tVqMLI1YyHe8uXSGqQ=; b=p2a71qmSzLmmQ3UOxxIoQSV/2KdC/yC9vHeLSFUlV+A2GgUtqsopHy5fTCuDm2XxV4 SzZ+V8rkpHxrBxf+kyioCZ7ow3dUNgXuHRJSaF4YbmQ7B5yT+DD47PKbK9Aog6IBPLUe QT/U8vY50DK/uKwoHOAyr5C/DEvnDX2cdWAnw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ia8b6Tv23UtnudzU3UK66+KCIevjunB8ymovqpDlVx5kw0t/B85GWEPh7XuGZ8W4NQ Ldles1MMSX5JlRKuP7sm4eYFUVo8bunsT/27P49G3j/simeYSQqI+jT8hxlKSi3MRJCn VDbyGVFb7QGnfiTCnXFCanTL949K1S5LGoGfs=
In-reply-to: <20090213115644.GA752@xxxxxxxxxxxxxxxxxxx>
References: <bd9056300902121658p444e7fdbue96772cdc1702903@xxxxxxxxxxxxxx> <4ef5fec60902121931k66d4fd48pe68ccd7a3b437e3c@xxxxxxxxxxxxxx> <bd9056300902130055i7f849908w88d84857aa5eb871@xxxxxxxxxxxxxx> <20090213115644.GA752@xxxxxxxxxxxxxxxxxxx>
Reply-to: or-talk@xxxxxxxxxxxxx
Sender: owner-or-talk@xxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Drake Wilson wrote:
(snip)
> 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.)
(snip)

This is why in the roadmap for the future of the Tor project, one of the
goals is to switch from TCP to UDP as the transport protocol for the
overlay connections.

Indeed, UDP would be more efficient, since any TCP protocol being
tunneled within it would have its own sequencing, etc.; it also would
(potentially) allow UDP-based protocols to not only be tunneled, but
tunneled efficiently.

(It's interesting that this problem was discussed regarding the Hamachi
zero-config VPN program; it uses UDP for its encapsulated packets, and
allows any enclosed TCP streams to use their own sequencing.)

- --
F. Fox
Owner of Tor node "kitsune"
http://fenrisfox.livejournal.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBCAAGBQJJlXwTAAoJECxKjnsrYHNHqxsP/13Y0IIppWmElZFlUEus1cxY
BgB11/nikfAPe5SwyzI7uo7Phm2UbsamqqdpDB34nI4nNrqqLAV+tzyklyOD+mHV
7t8cU5l10w96gdIX9SiBhALPMx0ssKlDLwf1YDBGLwXEJ0VBlhy71GZGwZrYw4UJ
LM8JeyyoxxKEsLL6Aaou713B5t8j5lMUyYJ/DmCvHR6gi0JTQLYqXppC3axN1afE
afGat+XJCbikOzo/lKnDWQ3Y5BcHNHth1pjYiLBzjhCIs8fjs8WPEVuz/xvPsrGf
q7j8Nz2zWuWACca7Td6+Wv3MtajK8uK22cjroHCpbHtef8HLEdUaJ4hgdoF1Vkg2
V8s7XfkX/yaL28cOld4UN+QDm1Uub3+PqUUCyZvMVGuRKj2JKyiPvTf4CfLtyUe5
W1aDUorzml5/i8dAGPgski3PrEmZV6Egrxsh8n5+ed6Bi9xX/885yfjGNXQWyARF
fG6dKyjHVVcylVFDYEiGLyiJJsHEKCcCvmj2GKmsMkrJ0igGpJ8jwfaunL3f/LsJ
ZIDJITwuJd7+2pKsT3H5SfumBMrsI5PTuAZlVgFUzEcWE3SVZRl1hinGxfxneIw2
QyEEznAYvc+5Uyfzv3g4dY9hPqzKo5ZGZf171WItH0lQXjE98sHwaPSKksPHNx/E
/foC+o+3I+PwSfnE8jhJ
=X67u
-----END PGP SIGNATURE-----

Follow-Ups:
- Re: Tor speed
  - From: Fran Litterio

References:
- Tor speed
  - From: slush
- Re: Tor speed
  - From: coderman
- Re: Tor speed
  - From: slush
- Re: Tor speed
  - From: Drake Wilson

Prev by Author: Re: Some Bones to Pick with Tor Admins
Next by Author: Re: Tor speed
Previous by thread: Re: Tor speed
Next by thread: Re: Tor speed
Index(es):
- Author
- Thread