Fwd: Fwd: [p2p-hackers] For fans of datagram
Adam Langley
agl at imperialviolet.org
Mon Sep 5 21:10:19 UTC 2005
Context forward 2/2
---------- Forwarded message ----------
From: Nick Mathewson <nickm at freehaven.net>
Date: Sep 5, 2005 9:16 PM
Subject: Re: Fwd: [p2p-hackers] For fans of datagram
To: Adam Langley <agl at imperialviolet.org>
Cc: tor-assistants at freehaven.net
{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 at mit.edu> 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 at imperialviolet.org
http://www.imperialviolet.org (+44) (0)7906 332512
PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60
More information about the tor-dev
mailing list