From 08fd72fb06d8262eb65300aaac98a9e2248d8489 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 17 May 2006 02:18:35 +0000 Subject: [PATCH] finally write some comments on tor-spec-udp.txt svn:r6455 --- doc/tor-spec-udp.txt | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/doc/tor-spec-udp.txt b/doc/tor-spec-udp.txt index df96e6a657..9e4966c8c4 100644 --- a/doc/tor-spec-udp.txt +++ b/doc/tor-spec-udp.txt @@ -387,3 +387,28 @@ Switching to UDP means managing the queues of incoming packets better, so we don't miss packets. How does this interact with doing large public key operations (handshakes) in the same thread? +======================================================================== +COMMENTS +======================================================================== + +[16 May 2006] + +I don't favor this approach; it makes packet traffic partitioned from +stream traffic end-to-end. The architecture I'd like to see is: + + A *All* Tor-to-Tor traffic is UDP/DTLS, unless we need to fall back on + TCP/TLS for firewall penetration or something. (This also gives us an + upgrade path for routing through legacy servers.) + + B Stream traffic is handled with end-to-end per-stream acks/naks and + retries. On failure, the data is retransmitted in a new RELAY_DATA cell; + a cell isn't retransmitted. + +We'll need to do A anyway, to fix our behavior on packet-loss. Once we've +done so, B is more or less inevitable, and we can support end-to-end UDP +traffic "for free". + +(Also, there are some details that this draft spec doesn't address. For +example, what happens when a UDP packet doesn't fit in a single cell?) + +-NM