Quoth Scott Bennett <[email protected]>, on 2009-02-13 07:27:10 -0600: > >TCP connection has much more of this than would be present if one were > >using the underlying packet network more directly, I think.) > > But I don't think reimplementing all of that over UDP is necessarily > the optimal way to go about it.
I'm not sure who proposed reimplementing Tor with UDP... ? > >Using a protocol like SCTP might help with this, but that brings up > >various other annoying practical problems that are particularly > >annoying because there's no good reason for them to exist. > > > Such as? A list of pros and cons is the kind of elaboration I've > been hoping to get. I've been examining SCTP during some of my Copious Free Time as part of some (non-Tor) research on relay networks. (Pardon my verbosity in the following paragraphs.) The advantages are mainly the desirable features of SCTP that are not easily replicable with TCP or UDP: multiple streams per association, a goodly amount of control over ordering constraints and (I think) reliable versus unreliable delivery, while retransmissions and packet boundaries are still handled for you at the transport layer rather than having to fold them into an application-layer protocol, and so forth. As I see it, one main problem with native SCTP if you expect random people on the Internet to run relays is the toxic black moldy outgrowth of NAT everywhere. In the presence of NAT, direct access to the original transport-protocol-agnostic packet network between the hosts is lost, so the NAT box has to handle remapping port numbers in transport protocols. "NAT box", here, includes huge swathes of consumer-grade "routers", which will (at least in my experience and by extrapolation) mostly fail to understand SCTP, because it's not commonly used, and they have no incentive to put another code path in that takes up space and time and might cause bugs. Tor already requires people to set up TCP port forwarding, which is a potential barrier to becoming a relay; for people using consumer-grade NAT on their Internet connections, doing SCTP port forwarding or similar tricks may be close to impossible. A secondary, similar problem might be restrictive perimeter firewalls or intrusion detection systems that deny all unrecognized transport protocols because they don't know how to inspect them; I've seen university networks with these, for instance. I don't know how common this is, nor how the set of locations with such restrictions correlates with the set of locations where people want to operate relay nodes. It's possible to get around some of the above by layering SCTP on top of UDP, which is quite ugly but may be less ugly than designing a new transport layer from scratch; there's an "interim protocol" for this designated by the experimental-status sigtran-sctptunnel-00 Internet-Draft (which expired in August 2000). That uses a daemon that tunnels SCTP using a single reserved UDP port, which can create deployment problems if applications are assumed to only allocate TCP and UDP ports for themselves, which is a common assumption. Presumably it would be easy to define SCTP over single application-assigned UDP ports based on the existing draft, but this wouldn't interoperate with existing native SCTP implementations, which is a pain. There may be issues with operating system support. Several Unix-like systems support SCTP directly; Windows seems to require an extra userspace library. This can presumably all be handled with application-level glue code; I don't know how much implementation complexity it adds to handle both cases for SCTP versus TCP. The latter seems likely to be better-known, making it easier to find information and existing multiplatform glue code. That's what I've learned so far; as you can see, my knowledge is incomplete. I'd welcome additions or corrections, certainly; if there's going to be extended discussion on this topic, though, it might be better to do it off-list, since it's not directly Tor-related. ---> Drake Wilson
