On 9. okt. 2013, at 18:27, Yuchung Cheng <[email protected]> wrote: > > > > On Wed, Oct 9, 2013 at 3:03 AM, Michael Welzl <[email protected]> wrote: > [ Saying what I should have said before: Let's please have this discussion > on the [email protected] list (in cc); subscription info: > https://sites.google.com/site/transportprotocolservices/ ] > > Indeed, also SCTP works over UDP, and is being shipped that way with Firefox > already. Then you have LEDBAT, over UDP, being used in BitTorrent; then, you > have, also over UDP, Google's QUIC and Adobe's RTMFP. Let's not forget the > SCTP'ish services provided in the form of a TCP++ in Minion. And, finally, we > could use e.g. native SCTP today, with Happy Eyeballs. > > For example, to get faster delivery of messages without requiring their > correct order, I could choose, just to name a few: > - TCP with Minion, if the other side supports it (from a quick glance at the > two drafts, I couldn't see how Minion support on the other side is identified > / negotiated? Either I missed it, or this part is still undecided) > - SCTP native, if the network and the other side supports it (which I can > test with Happy Eyeballs) > - SCTP over UDP, if the network and the other side supports it > - QUIC, I think > > If we could hide these choices under a common API, and identify which > services have enough agreement behind them (because they're published in RFCs > and/or deployed and used in applications), then we could perhaps work towards > a cleaner and more flexible situation. Not agreeing on things means that > we'll get more and more transports-over-UDP in applications for which the > programming effort pays off, and many applications that don't work as good as > they could because the benefit of using something other than TCP just doesn't > outweigh the effort for the programmer. > > Consider the web: we've long known that web transfers work better with SCTP: > http://www.eecis.udel.edu/~leighton/firefox.html > but only now, a transport-level improvement for the web is happening thanks > to Google's QUIC, because we first needed a company that is in control of > both the server and the browser for the programming effort to be worth it. > (Why let your browser do happy eyeballs, and put SCTP code in there, when > servers don't support SCTP anyway? Why support SCTP in your server when > browsers don't request it?) If SCTP usage would have been provided > automatically, hidden underneath the API, with a fall-back, we could have had > a faster web long ago, I reckon. > QUIC is a counter example of this transport service concept. It's 100% > custom-fit for SPDY and boosts performance by breaking current layers (no > judgement here). For example, it tightly integrates the existing SSL and TCP > to enable snap-start 0-RTT open, and encrypts all its headers to defend > middlebox tinkering. > > If an app wants absolute performance or critical features it needs a > tailor-made transport. Or they can use SCTP/udp or TCP. > > What real problems do this new transport service solve?
None, for your application, if (as in case of Google) it pays off for you to put your own new transport protocol in there, or use SCTP/UDP. SCTP also isn't easy to use (RFC 6458 has 115 pages), and a part of this effort is to aim at being able to provide a simplified API; I think that application programmers should be able to benefit from more than what TCP and UDP now give them, without having to worry about performance-enhancing mechanisms that can be done with knowledge about the network, but are not application-specific. Making this more concrete, take multistreaming for example - this could be done by the transport layer without bothering the application programmer with "do you want this or not?". We have a differentiation: application developers for whom the effort of playing with e.g. SCTP/UDP or building their own protocol pays off, and all the rest. All the rest could well benefit from having a bit more than UDP and TCP available, if it was easy to use - but finding a "killer application" will be hard. A killer application would already be successful, which means that, if high performance networking is important for it, the effort would now pay off, because the company has grown to a level where it's worth the effort. Cheers, Michael
