Subject: Transport Services

From: Michael Welzl <[email-masked]>
Date: Thu, 7 Nov 2013 11:28:05 -0800

Hi,

In today's session on the evolution of the transport layer, there was a lot of talk on improving the API from applications to the transport layer, both in some presentations and in the discussion now.

I'll use this chance to remind everyone that I'm making an effort to get just that done - with a planned BOF at the London IETF. So if you're interested in this, please join us, at:
https://sites.google.com/site/transportprotocolservices/

List: https://sympa.uio.no/ifi.uio.no/info/transport-services

I thought an email is more helpful than going to the mic because this gives you the URL  ;-)

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 7 Nov 2013 11:31:17 -0800

btw - an add-on (sorry for the extra email)

If you are quick to look at our draft charter, you may be disappointed by seeing 1) no concrete implementable stuff planned and 2) having a narrow set of services that is based only on the transport protocols that we now have, and not really looking at applications want.

As a result of discussions at this IETF, both 1) and 2) will be fixed. This is really the plan, just the current charter text doesn't yet reflect that.

Cheers,
Michael

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 11 Nov 2013 21:07:09 +0000

Michael, 

Can you give some examples of the  "internet applications" stated? 

Linda

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Welzl
> Sent: Thursday, November 07, 2013 1:31 PM
> To: [email-masked]
> Subject: Re: Transport Services
> 
> If you are quick to look at our draft charter, you may be disappointed
> by seeing 1) no concrete implementable stuff planned and 2) having a
> narrow set of services that is based only on the transport protocols
> that we now have, and not really looking at applications want.
> 
> As a result of discussions at this IETF, both 1) and 2) will be fixed.
> This is really the plan, just the current charter text doesn't yet
> reflect that.
> 
> Cheers,
> Michael
> 
> 
> 
> > In today's session on the evolution of the transport layer, there was
> a lot of talk on improving the API from applications to the transport
> layer, both in some presentations and in the discussion now.
> >
> > I'll use this chance to remind everyone that I'm making an effort to
> get just that done - with a planned BOF at the London IETF. So if
> you're interested in this, please join us, at:

---

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Nov 2013 10:33:58 +0100

Hi,

This is really for any application that can benefit from a service that's different from TCP and UDP with nothing on top (more about UDP below).

Examples include:

- web browsers: here one can greatly benefit from multi-streaming, which can be hidden underneath an API and automatically provided. For an example of the benefits that can be attained that way, see:
http://heim.ifi.uio.no/~michawe/research/publications/globecom2011.pdf
... this is multi-streaming at the transport layer, i.e. it doesn't have the RTT-timescale HOL delay that SPDY's multi-streaming over TCP would have (which, I suspect, is one of the major reasons for Google to build QUIC).

- games: here one will have delivery deadlines after which it makes no sense to retransmit the old data (a function SCTP provides)

- streaming apps: here one might want to use a LEDBAT'ish service for pre-fetching as the buffer gets full enough, and perhaps delivery deadlines too...

- interactive multimedia apps such as video/audio communication: maybe you want a smoother-than-TCP congestion control here?

You might wonder why anyone would need this, given that exactly these applications seem to have their own, more ideal solutions embedded (Skype, Adobe Flash, Chrome ... they all have their own protocols). Indeed, I suspect that it's no big win for such applications to use my envisioned more flexible transport layer, as one can always do better above UDP (for one, no need to deal with all the standardization compromises). So I think this work targets cases where the company developing an application can't afford to invest the time/money to develop their own UDP-based protocol.

Today's choice is either to have a pretty bad old service (UDP with nothing, or TCP as it is) or to build a lot of stuff by yourself. The intention is just to fix that - to give more services to everyone and make them easy to use.

Another major target application, if we can call it that, is middleware: any layer that provides an abstraction of the socket interface to applications above. Maybe some of these abstractions could nicely be mapped onto a more extensive set of transport services than what TCP and UDP provide, to the immediate benefit of all applications using the middleware.

Of course, once we make more services available and make the easy to use, one can imagine things that aren't happening now. e.g., why not pre-fetch stuff in browsers in a LEDBAT style? And the abstractions of the socket interface I was mentioning could also be extended to provide a richer set of services (specify deadlines, give priorities for a data transfer, whatnot...).

This may sound like I'm promising a whole world of things    :-)    - what I really think is that the transport layer should offer them, but all on a best-effort basis, i.e. you may still get less efficient standard TCP as a fall-back, and you wouldn't even be told... or the API would say "can't" - personally I'm in favor of the "don't tell, best-effort" approach for simplicity, but this is exactly the kind of discussion that I think a Transport Services WG should have.

I hope the idea is clearer now? We're trying to get the charter as clear as possible at:
https://sites.google.com/site/transportprotocolservices/

Cheers,
Michael