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

[Adam Langley <agl@xxxxxxxxxxxxxxxxxx>]

Context forward 2/2

---------- Forwarded message ----------
From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
Date: Sep 5, 2005 9:16 PM
Subject: Re: Fwd: [p2p-hackers] For fans of datagram
To: Adam Langley <agl@xxxxxxxxxxxxxxxxxx>
Cc: tor-assistants@xxxxxxxxxxxxx


{BTW, this conversation really belongs on or-dev.  Any objection to
taking it there?}

On Sun, Sep 04, 2005 at 07:00:58PM +0100, Adam Langley wrote:
> 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

Right, and thanks for the excellent analysis.  I'd suggest that others
might want to also want to check out section 4.1 of our "Challenges"
paper draft at
     http://tor.eff.org/cvs/doc/design-paper/challenges.pdf
which describes some more problems with moving from a stream-based to
a packet-based design.

This stuff would, of course, be potentially valuable, but it does seem
quite hard.  We'd love for someone to do the design work to prove us
wrong, though.

Some other points:

[...]
> 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.

I'd need to see more of a design here to see what you're really doing
before I could answer with any confidence.  Do you have anything written
you could send a pointer to?

In particular, you have a problem with cells from UDP circuits vs
cells from TCP circuits.  Only TCP cells should get GSD, or else all
hell will break loose.  But if encryption happens once per cell, then
TCP-carrying cells would become distinguishable from UDP-carrying
cells, since the latter would never get retransmitted.

Still, the design you have in mind may not have this flaw.

 [...]
> 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.

It does have the problem of making congestion-based path detection
even easier, though.

 [...]
> 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.

Right.  DCCP is hard enough to find and deploy that we might need to
consider a dual-moded OR connection protocol: try DCCP if both sides
support it, and fall back to TCP if it doesn't work.

Of course, who knows whether DCCP will ever see enough uptake to make
this work.

yrs,
--
Nick Mathewson




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