Fwd: Fwd: [p2p-hackers] For fans of datagram

[Adam Langley <agl@xxxxxxxxxxxxxxxxxx>]

Context forward 1/2

---------- Forwarded message ----------
From: Adam Langley <agl@xxxxxxxxxxxxxxxxxx>
Date: Sep 4, 2005 7:00 PM
Subject: Re: Fwd: [p2p-hackers] For fans of datagram
To: tor-assistants@xxxxxxxxxxxxx


On 9/3/05, Roger Dingledine <arma@xxxxxxx> wrote:
> Would you like to put some thought into transitioning Tor
> to handle dtls for the links if both sides understand it? :)
>
> This will be a really handy feature for using Tor on lossy networks.

Well, there are other reasons to want to use datagram transports
between Tor nodes:
  1) No cross-circuit order preservation
  2) The ability to handle UDP traffic

1) At the moment a number of different circuits are multiplexed down a
single TCP connection because TLS connections are expensive. However,
TCP is enforcing ordering of packets across all circuits where as we
only want to enforce it for each circuit. A dropped packet shouldn't
need to hold up the rest of the circuits on a single connection

2) Putting UDP traffic down the TCP connections is possible, of
course, but very messy. Most UDP applications (being real-time stuff
in many cases) is paying lots of attention the the packet loss and
round trip time. Putting that down an inorder pipe is going to wreck
them in the same way that TCP in TCP turns into a stinking mess.

So that's why we want it.

As for the how we are looking at something like:

IP / UDP / CC&GSD layer / DTLS

(CC = congestion control, GSD = guaranteed single delivery)

We could put DTLS under the CC layer, but that would mean extra
encryption for retransmissions and ACKs etc. At the moment we don't
protect our connection-metadata (the TCP header) and, unless someone
sees an advantage, I don't see that we should start doing so.

Before I get to the choice of CC layer, we should also take this
chance to introduce real circuit flow control. At the moment we have
end-to-end flow control, but at each node in the circuit we have big
buffers (16MB) and we just hope like hell that we don't overflow it.
If we do, the connection is dropped. That's wrong.

We need per-circuit flow control between directly connected nodes.
There should be a default window size assumed when a connection is
setup and then explict "bucket refill" packets can be sent to tell the
other side that you are happy to have more data for circuit X. This
removes the need for large buffers and for dropping connections
needlessly.

The window size should be such that we don't expect more than that
amount of data to be "in the wire" between the bucket high and low
water levels. The nodes can measure that, of course, and should if we
want to support private Tor networks on high speed connections well,
but a default size of 100KB should be resonable.

(note that this can be done with or without any kind of datagram work)

Back to the CC/GSD layer:

AirHook is pretty well known in this respect, but has fatal flaws:
   * The max micropacket size is 256 bytes, we have 512 byte cells
   * We don't want GSD all the time. UDP circuits must not have this (see above)

The next biggest wave in this world is DCCP. It doesn't force GSD on
us, but it's a replacement for UDP, rather than a layer over it. That
means that it's kernel implementation world (or root processes with
RAW sockets, ick!). The Linux implementation is coming on (of course)
but we cannot expect wide spread deployment for years. Also, it
probably goes through firewalls like a bird thru a jet engine.

If anyone knows another good candidate for that layer, please tell me
(I'm interested in general), but it would appear that we would have to
write our own. The DCCP spec (and the DCCP CCID 2&3 specs) suggest
most of a design for us, but it would still be a fair lump of code
(TorHook, anyone?)


AGL

--
Adam Langley                                      agl@xxxxxxxxxxxxxxxxxx
http://www.imperialviolet.org                       (+44) (0)7906 332512
PGP: 9113   256A   CC0F   71A6   4C84   5087   CDA5   52DF   2CB6   3D60


-- 
Adam Langley                                      agl@xxxxxxxxxxxxxxxxxx
http://www.imperialviolet.org                       (+44) (0)7906 332512
PGP: 9113   256A   CC0F   71A6   4C84   5087   CDA5   52DF   2CB6   3D60