Maybe that's all for today

There are some really big TODOs that I need to crack open but maybe
that's a job for after break.

Happy new year!

1 files changed, 22 insertions, 10 deletions

diff --git a/proposals/XXX-udp-app-support.md b/proposals/XXX-udp-app-support.md
index 350f91b..bdea42b 100644
--- a/proposals/XXX-udp-app-support.md
+++ b/proposals/XXX-udp-app-support.md
@@ -76,8 +76,9 @@ To better specify the role of a UDP extension for Tor, we will look at a few fra
 
 ## User Datagram Protocol (RFC768)
 
-The "User Interface" suggested by RFC768 for the protocol is a rough sketch, suggesting that applications have some way to allocate a local port for receiving datagrams and to transmit datagrams with arbitrary headers.
+The "User Interface" suggested by [RFC768](https://www.rfc-editor.org/rfc/rfc768) for the protocol is a rough sketch, suggesting that applications have some way to allocate a local port for receiving datagrams and to transmit datagrams with arbitrary headers.
 Despite UDP's simplicity as an application of IP, we do need to be aware of IP features that are typically hidden by TCP's abstraction.
+
 UDP applications typically try to obtain an awareness of the path MTU, using some type of path MTU discovery (PMTUD) algorithm.
 On IPv4, this requires sending packets with the "Don't Fragment" flag set, and measuring when those packets are lost or when ICMP "Fragmentation Needed" replies are seen.
 
@@ -89,10 +90,11 @@ In practice the straightforward "User Interface" from RFC768, capable of arbitra
 
 BSD-style sockets support UDP via `SOCK_DGRAM`.
 UDP is a stateless protocol, but sockets do have state.
-Each socket is bound, either explicitly with 'bind()' or automatically, to a source IP and port.
-At the API level, a socket is said to be _connected_ to a remote address:port if that address is the default destination.
-A _connected_ socket will also filter out incoming packets with source addresses different from this default destination.
-A socket is considered _unconnected_ if 'connect()' has not been called.
+Each socket is bound, either explicitly with `bind()` or automatically, to a source IP and port.
+
+At the API level, a socket is said to be *connected* to a remote address:port if that address is the default destination.
+A *connected* socket will also filter out incoming packets with source addresses different from this default destination.
+A socket is considered *unconnected* if `connect()` has not been called.
 These sockets have no default destination, and they accept datagrams from any source.
 
 There does not need to be any particular mapping between the lifetime of these application sockets and any higher-level "connection" the application establishes.
@@ -208,6 +210,11 @@ QUIC does not normally try to traverse NAT; as an HTTP replacement, the server i
 
 TODO: Look closer at the NAT rebinding attack described in the RFC, check how applicable that is for us.
 
+When QUIC is used as an optional upgrade path, we must compare any proposed UDP support against the baseline of a non-upgraded original connection.
+In these cases we are not looking for any specific compatibility enhancement, simply an avoidance of regression.
+
+In cases where QUIC is used as a primary protocol without TCP fallback, we expect UDP support to be vital. These applications are currently niche but we expect they may rise in popularity.
+
 ### WebRTC
 
 WebRTC is a large collection of protocols tuned to work together for media transport and NAT traversal.
@@ -251,19 +258,24 @@ In alphabetical order:
 
 # Design approaches
 
-TODO
+Now that we've defined some categories of UDP traffic we are interested in handling, this section starts to examine different implementation techniques.
+
+We can broadly split these into *datagram routing* and *tunneling*.
 
 ## Datagram routing
 
-TODO
+These approaches seek to use an anonymity network that can directly route datagrams from place to place.
+These approaches are the most obviously suitable for implementing UDP, but they also form the widest departure from classic Tor.
 
 ### 3rd party implementations
 
-TODO
+TODO: What examples do we have of 3rd party mixnets that already have these desirable datagram properties? i2p would be a good reference point here, but only for the mixnet portion itself not for any kind of exit bridge.
 
 ### Hybrid approaches
 
-TODO: Idea about splitting UDP and TCP traffic. Applicable to clearnet (Tor/3rd-party split) and to onion (Exit/Rend split)
+TODO: If we do have a good story for some potential datagram mixnet above, examine the possibility of splitting traffic between Tor and that network.
+
+TODO: Also discuss splitting traffic between exit and rend for onions? This is technically more likely to be useful for tunneling below, so maybe we don't go into it here.
 
 ### Making room for a future Tor implementation
 
@@ -353,7 +365,7 @@ TODO: Exit selection is likely common to both of these approaches. Talk about ho
 
 ## Tor UDP Mapping Protocol
 
-This is *tunneled* approach, using Tor's existing protocol objects where possible. Exits advertise support for specific UDP policies. Clients choose an exit where they would like to allocate a UDP local port. They create one *stream* with a lifetime matching the lifetime of that mapping. Optional additional *streams* may be used as fast paths for common peers. This is the *hybrid approach* to stream usage, from above.
+This is a *tunneled* approach, using Tor's existing protocol objects where possible. Exits advertise support for specific UDP policies. Clients choose an exit where they would like to allocate a UDP local port. They create one *stream* with a lifetime matching the lifetime of that mapping. Optional additional *streams* may be used as fast paths for common peers. This is the *hybrid approach* to stream usage, from above.
 
 - `NEW_UDP_MAPPING`