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? > > 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 > > >
