Re: use of SCTP in volunteer relay networks (a bit off-topic)

[Drake Wilson <drake@xxxxxxxxxxxx>]

Quoth Scott Bennett <bennett@xxxxxxxxxx>, 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