Subject: Call for participation: Transport Services

From: Michael Welzl <[email-masked]>
Date: Tue, 8 Oct 2013 13:57:22 +0200

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

---

From: Matt Mathis <[email-masked]>
Date: Tue, 8 Oct 2013 09:15:07 -0700

I'm sorry if I haven't been paying attention, but what do you mean by "the
topic of transport services"?

Several things come to mind:
- please deliver my data
- y/n reliable delivery
- y/n out-of-order delivery
- y/n fast connect, w/ or w/o crypto protection
- optimize for min latency vs optimize for max throughput
- weighted congestion control for fine tuning priorities
- y/n multiple paths or endpoints
- y/n "nat compatible"
- y/n for event notification (up/down etc)
- etc
In varying degrees we know how to do most of these in both TCP and SCPT.
 The trick to providing them as "services" is to unbundle the (sub)layers.
 If you mean to design a API, I think you will find that the IETF has a lot
of trouble with stuff that is not visible on the wire, and has repeatedly
failed to converge on such issues.

Your broadcast message should have included "Please discuss on xxxx list."

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Tue, Oct 8, 2013 at 4:57 AM, Michael Welzl <[email-masked]> 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.
>
> 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
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Oct 2013 13:15:14 -0700

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:
> with potentially interested folks...  (this should be okay to do
> according to RFC5434, which says "various mailing lists").
>
> "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.
>

---

From: <[email-masked]>
Date: Wed, 9 Oct 2013 05:45:14 +0100

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-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: 08 October 2013 21:15
To: Michael Welzl
Cc: [email-masked]
Subject: Re: Call for participation: Transport Services

Hi, Michael, et al.,

Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 9 Oct 2013 11:31:22 +0200

Hi,

> Your broadcast message should have included "Please discuss on xxxx list."

Apologies!  The best I can do is say it now: please discuss on the [email-masked] list (in cc); subscription info: https://sites.google.com/site/transportprotocolservices/

On 8. okt. 2013, at 18:15, Matt Mathis wrote:

> I'm sorry if I haven't been paying attention, but what do you mean by "the topic of transport services"?
> 

I'd include many but not all of the things above. A part of the exercise of working towards a BOF is to agree on how to decide which things would and wouldn't be included in a list of transport services, and a first stab at the approach for arriving at a list is included in our initial charter proposal:
https://sites.google.com/site/transportprotocolservices/home/charter-proposal-before-bof
(the steps 1, 2, 3).

If this sounds too abstract, I can go through your list above case-by-case using the method described there, leading to "in", "probably in, but represented in another way", "out" decisions for every item in the list I think - but right now I'll refrain from doing that to avoid making this email unnecessarily long.

> In varying degrees we know how to do most of these in both TCP and SCPT.  The trick to providing them as "services" is to unbundle the (sub)layers.

Yes.

> If you mean to design a API, I think you will find that the IETF has a lot of trouble with stuff that is not visible on the wire, and has repeatedly failed to converge on such issues.

I mean to design services that would be exposed by an API, and describe example API implementations.
(which is a politician's way of saying "yes, I want to design an API", I guess   :-)   )

About what's visible on the wire: imagine that, instead of having the transport mechanisms that applications want embedded in the applications, we'd have a transport system underneath an API that we could just ask for a certain service instead of only requesting "TCP" or "UDP". Then clients would like to tell servers what kinds of services they'd like to have or which services they could accept. This signaling would have to specify a transport service (so there you have something on the wire) - but without having a standardized list of transport services, all a client can ever do is to signal services that it *knows* to be available on the other side. Without a standardized list, the only way to know what's available is if it's the same application - e.g. Skype talking to Skype. So this is how we're stuck with a situation where every application that needs a bit more than TCP's behavior from the network has its own UDP-based transport solution built in. I think the first step towards breaking this up is to agree on services and define them (and write the code, which some folks involved in this are doing).

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 9 Oct 2013 12:03:37 +0200

[  Saying what I should have said before: Let's please have this discussion on the [email-masked] 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

---

From: <[email-masked]>
Date: Wed, 9 Oct 2013 11:18:44 +0100

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

________________________________________
From: Michael Welzl [[email-masked]]
Sent: 09 October 2013 11:03
To: Wood L  Dr (Electronic Eng)
Cc: Joe Touch; [email-masked]; [email-masked]
Subject: Re: Call for participation: Transport Services

[  Saying what I should have said before: Let's please have this discussion on the [email-masked]<mailto:[email-masked]> list (in cc); subscription info: https://sites.google.com/site/transportprotocolservices/  ]

Cheers,
Michael

On 9. okt. 2013, at 06:45, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Lloyd Wood

Hi, Michael, et al.,

Joe

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

---

From: "LOCHIN Emmanuel" <[email-masked]>
Date: Wed, 09 Oct 2013 15:59:05 +0200

> 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

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 9 Oct 2013 09:27:41 -0700

On Wed, Oct 9, 2013 at 3:03 AM, Michael Welzl <[email-masked]> wrote:

> [  Saying what I should have said before: Let's please have this
> discussion on the [email-masked] 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)
> 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?

---

From: Michael Welzl <[email-masked]>
Date: Wed, 9 Oct 2013 22:42:46 +0200

On 9. okt. 2013, at 18:27, Yuchung Cheng <[email-masked]> wrote:

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

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

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 10 Oct 2013 05:10:33 -0700 (PDT)

Michael,

We have been working on a unified mechanism for Inter Layer Communication (ILC) and Simplified Congestion Control (SCC) for all apps to use.

From looking at your draft charter, I am not sure that this fits into your group.  Will you be having a meeting in Vancouver to discuss?  Did I miss that email?
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Michael Welzl <[email-masked]>
To: Matt Mathis <[email-masked]> 
Cc: [email-masked]; [email-masked] 
Sent: Wednesday, October 9, 2013 2:31 AM
Subject: Re: Call for participation: Transport Services

Hi,

I'll start with this:

About what's visible on the wire: imagine that, instead of having the transport mechanisms that applications want embedded in the applications, we'd have a transport system underneath an API that we could just ask for a certain service instead of only requesting "TCP" or "UDP". Then clients would like to tell servers what kinds of services they'd like to have or which services they could accept. This signaling would have to specify a transport service (so there you have something on the wire) - but without having a standardized list of transport services, all a client can ever do is to signal services that it *knows* to be available on the other side. Without a standardized list, the only way to know what's available is if it's the same application - e.g. Skype talking to Skype. So this is how we're stuck with a situation where every application that needs a bit more than TCP's behavior from the network has its own UDP-based transport solution built in.
 I think the first step towards breaking this up is to agree on services and define them (and write the code, which some folks involved in this are doing).

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 10 Oct 2013 14:54:17 +0200

Hi,

I updated the subject...   I hadn't made a plan for meeting yet; given the many collisions people usually have in the evenings of the IETF week, the relatively low priority this will have to many, and the unknown number of people interested + on site, I suggest the following procedure:

Many of us will be at TCPM on Monday morning, which ends at 11:30; I will then stand at the IETF reception desk on Monday from 11:40 to 12:00, collecting people. If you show up in this time frame, you become part of a group that goes off to have lunch in the hotel together at 12:00, and will chat until up to 14:30 (the end of the next time slot, which doesn't contain anything related to TSV). If I find myself in a crowd of hundreds of people standing there, all craving for food on Monday lunch time, we'll use this chance to agree on a day and time for an evening meeting in a bar somewhere (making it a "real" bar BOF, with beer and stuff! woo hoo!), and I'll figure out a place and announce it on the transport-services list.

Again, the short version: Monday 11:40-12:00, reception desk. Be there and see what happens.

Cheers,
Michael

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 10 Oct 2013 06:09:56 -0700 (PDT)

Will be there for sure!
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Michael Welzl <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Matt Mathis <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, October 10, 2013 5:54 AM
Subject: Plan for Vancouver

Hi,

Cheers,
Michael

Michael,