[ 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. Cheers, Michael On 9. okt. 2013, at 06:45, <[email protected]> <[email protected]> wrote: > Transport protocols are built over UDP these days - LTP, Saratoga, even DCCP > and SCTP. That UDP goes underneath > for convenience doesn't change the question about what services apps can be > offered, and require - and UDP goes > through all the NATs I'm familiar with in operation. > > (Really looking forward to the UDP-Lite in UDP get-through-NAT document!) > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Joe > Touch [[email protected]] > Sent: 08 October 2013 21:15 > To: Michael Welzl > Cc: [email protected] > Subject: Re: Call for participation: Transport Services > > Hi, Michael, et al., > > I find it difficult to resolve this with the fact that basically only > TCP* gets through NATs, and the lack of widespread use of DCCP and SCTP. > > (* more specifically, transport "6" with a passing resemblance to TCP's > header format, esp. SYN segments) > > I.e., what's the point in an app asking for what it wants if the only > answer is "TCP"? > > This might be an interesting topic for a research prototype, but > otherwise seems out of scope for the IETF - esp., as was noted, given > the IETF's current 'appreciation' for the role of APIs in protocol design. > > Joe > > On 10/8/2013 4:57 AM, Michael Welzl wrote: >> Dear all, >> >> Sorry if you receive multiple copies of this! I sent it to all the lists >> with potentially interested folks... (this should be okay to do >> according to RFC5434, which says "various mailing lists"). >> >> A community of interest is being formed to gauge whether there is >> sufficient interest to host a BOF at the London IETF, on the topic of >> "Transport Services". The intention is to create a WG that would define >> the set of services that transport protocols offer to applications, such >> that applications could at some point in the future request a service, >> not a protocol. This could foster innovation (protocols could be tried >> out, with a fall-back, without requiring the application programmer to >> include such functionality); it could also give more freedom to whatever >> resides below the API to automatically make the best out of what it >> currently has available. >> >> If you're interested in this problem space, please visit the related >> webpage that I have set up: >> https://sites.google.com/site/transportprotocolservices/ >> There you'll find an initial stab at a charter and all information about >> the mailing list - please join us and participate in discussions! Thanks! >> >> Cheers, >> Michael
