[or-cvs] finally write some comments on tor-spec-udp.txt

[nickm@xxxxxxxx (Nick Mathewson)]

Update of /home/or/cvsroot/tor/doc
In directory moria:/tmp/cvs-serv10747/doc

Modified Files:
	tor-spec-udp.txt 
Log Message:
finally write some comments on tor-spec-udp.txt

Index: tor-spec-udp.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/tor-spec-udp.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -d -r1.3 -r1.4
--- tor-spec-udp.txt	10 May 2006 07:35:03 -0000	1.3
+++ tor-spec-udp.txt	17 May 2006 02:18:35 -0000	1.4
@@ -387,3 +387,28 @@ Switching to UDP means managing the queu
 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