Re: udp transport PoC

[coderman <coderman@xxxxxxxxx>]

On Tue, May 13, 2008 at 3:11 PM, Adam Langley <agl@xxxxxxxxxxxxxxxxxx> wrote:
> ...
>  Now it would appear that you have two issues to content with. Firstly,
>  you have a flow control issue between nodes and secondly a packet-loss
>  issue for an individual circuit.

flow control / congestion avoidance / tcp fairness will be near
impossible with userspace UDP.  splitting these functions would allow
you a bulk fraction of bandwidth for UDP payloads and a reliable
control channel (via simple DTLS timeout / re-xmit or more robust
airhook / SSCOP style control sessions for reliable datagram
transport)


>  Your flow control should probably be based on[2]. The description in
>  the TCP RFC now bares no relation to reality.

the problem with trying for true tcp fairness in a datagram transport
used among many peers in userspace is going to be timer resolution
(especially on win32, but still problematic in *nix).

i'd much prefer to see a robust fractional bandwidth allocation
specified for the datagram stack as a whole, than watch the poor
behavior of another attempted TCP over UDP in userspace.

(i admit a general bias against TCP fairness in userspace, so a grain
of salt with this $0.02..)


>  Your packet loss and windowing is pretty straight forward, so long as
>  it can signal packet loss events to the flow control. I don't have any
>  specific references here, common sense is as good as the state of
>  practice here.

i keep referencing airhook in these discussions, particularly because
some of the control communication changes tailored for a lossy
wireless environment map nicely to the latency / multi-hop issues Tor
DTLS will apply to reliable datagram communications between nodes.

a number of modifications would be needed, however, including the
larger windows and explicit IV management for the DTLS sessions.
(doing key schedule properly for the first DTLS implementation into
Tor would also solve the long standing thread contention issues with
SSL/TLS stream encryption/decryption across multiple CPU's in an SMP
system, for example)


aside from fingerprinting attacks, what other critical concerns exist?