Le Mercredi 9 Octobre 2013 12:18 CEST, <[email protected]> a écrit: > > Subscribed... > > Interesting to hear that sctp is alive and well in a browser.
FYI, Multipath TCP seems enabled in iOS 7 http://appleinsider.com/articles/13/09/20/apple-found-to-be-using-advanced-multipath-tcp-networking-in-ios-7 EL > It's not quite an API, but I wrote > http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports > to be able to select between multiple ways of transporting upper-layer > protocols. At the least, it would aid programmers in explicit > testing/debugging... > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________________________________________ > From: Michael Welzl [[email protected]] > Sent: 09 October 2013 11:03 > To: Wood L Dr (Electronic Eng) > Cc: Joe Touch; [email protected]; [email protected] > Subject: Re: Call for participation: Transport Services > > [ Saying what I should have said before: Let's please have this discussion > on the [email protected]<mailto:[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]<mailto:[email protected]>> > <[email protected]<mailto:[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
