Quoth Scott Bennett <[email protected]>, on 2009-02-16 09:38:42 -0600: > >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. [...] > The above is, of course, true right now, but the problem may well > fade away over the next few years, now that SCTP is an official protocol > for the Internet. W.r.t. electronics store routers, one only need note > the huge numbers of 802.11(draft)n devices being sold these days. People > want the new stuff,
People want the new stuff when it offers a perceived benefit to them. This is how I imagine the conversations going (dramatized): "So if I buy one of these fancy 'N' routers, what do I get?" "The wireless will be faster." "Oh, so when I'm sending those big batches of videos from my laptop it'll take one minute rather than ten minutes? Great, I'll pay extra for that." This is as opposed to: "So what does 'SCTP support' mean?" "It means you'll be able to access all the great stuff on the Internet that's only available through SCTP." "And which stuff is that?" "Well, nothing so far." "Then I think I'm going to stick with the one I have." Note that approximately no users actually look for "TCP support" or "UDP support" specifically on their consumer NAT boxen; it's implied. The only reason there's TCP support in these boxes is because if it isn't there, J. Sixpack will say "I can't load my games"; if SCTP support is absent, J. Sixpack will say nothing, and the first application that requires SCTP that wants the Sixpack family to be able to use it will die a horrible death. They won't see "Alice's App uses SCTP and has a much better protocol stack design as a result"; they'll see "Alice's App says it won't work with my router, even though it works with everything else on the Internet; Bob's Browser works just fine, even if it's a little slow sometimes", and guess which one will get used? Now, why am I talking about the Sixpack family when they're not likely to want to run a Tor relay in the first place? Because, near as I can tell, the ignorant users tend to dominate the market by default, and whatever sells to them the best will be whatever gets mass-produced cheaply; the converse effect then occurs, because people will want to use what's cheap, and as a result the influence of the masses spreads farther out. How much farther out, and how much does that apply here? My guess is that the effect is significant, but I don't have the data for that. It would be interesting to get some idea of what fraction of Tor relay operators are behind consumer-grade NAT boxen, for instance, or what fraction would be willing to replace their gateway boxen or do the work to upgrade their firewall scripts or such if it meant they could run a better relay protocol. There are presumably other forces that can overcome this effect, but they seem few and far between. > I'm not sure what to do about NAT, but how would that be any > different from the current situation? It's not that much different from the current situation in theory, but it's a classic bistable potential barrier to the implementation of new technology, pretty much a form of the network effect. Everybody accesses resources over TCP, so people making everyday NAT stuff implement TCP. When designing new protocols that will pass through these translators, people use TCP because that's what will work most easily, so everyone continues to access resources over TCP. Similarly, not nearly as many random people access resources over SCTP, so people making everyday NAT stuff ignore SCTP. When designing new protocols that will pass through these boxes, people avoid SCTP because it won't pass through them, so there continues to be nobody accessing resources over SCTP. The way to have the latter not be the case anymore is to achieve a critical mass of SCTP users. I see no reason to believe this will happen; see below re IPv6. There's nothing special about the SCTP in this case, either; if the Internet had originally been developed solely with UDP, and TCP were the new contender, ceteris paribus, it'd be having similar problems. This is the main reason I consider the outgrowth of pervasive masquerading NAT to be so distasteful; it causes these network effects to apply at the transport layer where ideally they should not be applying, largely negating the beneficial effect of separating network layer from transport layer in the first place. > NAT also might prove pretty much obsolete/unnecessary in IPv6, as > well. IPv6 has similar network-effect problems, only a little bit worse; DJB's page on "The IPv6 mess" [1] describes how the lack of embedding of IPv4 address space into IPv6 address space adds a large barrier to transitioning. I haven't seen a good counterargument to that yet, though I'm holding out hope that either some other force will moot it or that it'll be fixed at some point. In the specific case of IPv6, I think the address space pressure may force the matter eventually. [1] http://cr.yp.to/djbdns/ipv6mess.html > >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 > > That does sound nasty, but probably no worse than TCP over UDP. (Note that strictly speaking, one isn't layering TCP over anything unless one actually implements TCP per se TCP at that level; you seem to be talking about cases where people are implementing transport layers with TCP-like characteristics in order to transport what will ultimately be TCP streams at the ends.) > Yes, it's already in FreeBSD 7 and will probably be significantly > improved in FreeBSD 8. I don't use LINUX, so I can't comment on that. > (LINUX folks, please chime in!) The Linux 2.6 kernel that I use on my Debian GNU/Linux systems has native SCTP kernel-side. ---> Drake Wilson
