RE: Call for participation: Transport Services

[<[e-mail]>]

Subscribed...

Interesting to hear that sctp is alive and well in a browser.

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 [[e-mail]]
Sent: 09 October 2013 11:03
To: Wood L  Dr (Electronic Eng)
Cc: Joe Touch; [e-mail]; [e-mail]
Subject: Re: Call for participation: Transport Services

[  Saying what I should have said before: Let's please have this discussion on the [e-mail]<mailto:[e-mail]> 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, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> 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: [e-mail] [[e-mail]] On Behalf Of Joe Touch [[e-mail]]
Sent: 08 October 2013 21:15
To: Michael Welzl
Cc: [e-mail]
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