SCTP is the heir apparent [LWN.net]

SCTP is the heir apparent

Posted Nov 20, 2009 23:18 UTC (Fri) by perennialmind (subscriber, #45817)
In reply to: But supporting SCTP has to start somewhere ? Why? by khim
Parent article: Reducing HTTP latency with SPDY

When it comes to the open internet, I agree that it'll be a long, long time before SCTP could become broadly feasible, but that's because you're talking about upgrading a massive network. New protocols are not born on the internet, not anymore. New network protocols breed in the crevices of the LAN, and SCTP has a bright future there. Some of the newer protocols like SIP, iSCSI, and NFSv4 will happily sit atop SCTP. If you're going out to fix the same problems that SCTP tackles, at the very least they should define a mapping, as those protocols do. We don't need to keep the kruft forever, but it has to be a gradual upgrade. Encapsulate as needed: SCTP has a reasonable UDP layering. Because "internet access" translates to TCP port 80 for so many, you may have to define something like SPDY, but in that case shouldn't it simply be the TCP variant, on a level with SCTP? Even if it does take ten years, twenty years, won't you want to be able to drop the inefficient backwards compatibility at some point?

Comcast is upgrading their gear to IPv6 because /they/ need it. With the multi-homing support in SCTP, you should be able to sell it to Verizon, AT&T, Sprint, etc as being genuinely useful to /them/. They have the unique position of both owning the (huge) proprietary networks all the way to the edge and actually making substantial use of those same networks, so they have both the ability and the business interests to adopt SCTP that random servers and clients do not. Just because SCTP isn't ready to supplant TCP for the web, doesn't diminish it's usefulness, right now.

(Log in to post comments)

SCTP is the heir apparent

Posted Nov 22, 2009 0:56 UTC (Sun) by khim (subscriber, #9252) [Link]

Even if it does take ten years, twenty years, won't you want to be able to drop the inefficient backwards compatibility at some point?

Is it really so inefficient? Is it really impossible to make things more efficient while retaining compatibility? Witness fate of Algol which decided to "drop inefficient backwards compatibility at some point" and compare it with Fortran which kept it around for decades. And the same story is with RISC and x86. And other countless examples. Compatibility is very important: it can only be dropped if there are no compatible way forward.

Comcast is upgrading their gear to IPv6 because /they/ need it.

Wrong emphasis. /They/ is irrelevant. /Need/ is imperative word.

With the multi-homing support in SCTP, you should be able to sell it to Verizon, AT&T, Sprint, etc as being genuinely useful to /them/.

You can try do this, but it's almost too late. They are losing their network and are becoming just "another ISP" (albeit big one). AOL already went this way, Verizon, AT&T, Sprint will follow. Sure, they'll try to delay it as much as possible, and may be even survive long enough for SCPT to become the whole article in history books, not just a footnote, but ultimately it's not a big difference.