Subject: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88

From: Martin Stiemerling <[email-masked]>
Date: Wed, 23 Oct 2013 09:12:48 +0200

Dear all,

We would like to give time to the Transport Area to discuss any 
potential need to evolve the IETF transport protocols.

There are a number of proposals discussed in the IETF and outside of the 
IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of 
TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. 
QUIC [3]), and also discussions about the congestion control approach to 
be used (e.g., delay-based [4], LEDBAT [5]).

(We are fully aware that this list of proposals is incomplete)

Spencer and I are planning a slot in the TSVAREA session at IETF 88 in 
Vancouver to discuss this topic.

More information to come soon.

Let Spencer and me know at [email-masked] if you are interested 
in contributing actively to the session.

Thanks,

   Spencer and Martin, your TSV ADs.

References
[1] https://developers.google.com/speed/protocols/tcp-laminar
[2] http://tools.ietf.org/html/draft-iyengar-minion-concept
[3] 
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?pli=1
[4] https://datatracker.ietf.org/wg/rmcat/charter/
[5] https://datatracker.ietf.org/wg/ledbat/charter/

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 23 Oct 2013 10:53:59 -0400

> (We are fully aware that this list of proposals is incomplete)

One other protocol that has been floating around outside the IETF for
awhile is Saratoga, though we've talked about it a little in TSVWG
and there are a number of internet-drafts:
http://datatracker.ietf.org/doc/draft-wood-tsvwg-saratoga/
http://datatracker.ietf.org/doc/draft-wood-tsvwg-saratoga-congestion-control/
http://datatracker.ietf.org/doc/draft-eddy-tsvwg-saratoga-tfrc/

There are several interesting things about Saratoga related to transport
protocol evolution, so I thought it might be another interesting
datapoint in the field.  Off the top of my head, relevant features are:

- runs over UDP for deployability
- can run over highly asymmetric paths (e.g. 1000s-to-1 b/w ratio)
- flexibly implements different congestion control algorithms
- copes with extremely high latency or unidirectional connectivity

> in contributing actively to the session.

If it's of interest, I could briefly present the state of Saratoga
(e.g. 5 minutes), and possible future plans.

-- 
Wes Eddy
MTI Systems

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 Oct 2013 18:19:25 +0000

Martin and Spencer, 

Possible to include HTTP? More and more applications run HTTP, and many people believe that HTTP is the future of the transport protocol(s). 

Linda

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Stiemerling
> Sent: Wednesday, October 23, 2013 2:13 AM
> To: [email-masked]
> Subject: Announcing the TSVAREA session on "Evolution of IETF Transport
> Protocols" @ IETF-88
> 
> Dear all,
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 24 Oct 2013 15:20:44 -0400

On Thu, Oct 24, 2013 at 2:19 PM, Linda Dunbar <[email-masked]>wrote:

> Martin and Spencer,
>
> Possible to include HTTP? More and more applications run HTTP, and many
> people believe that HTTP is the future of the transport protocol(s).

QUIC is already mentioned.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 24 Oct 2013 12:31:52 -0700

Reminds me a bit of the situation early on in RMT. There where
so many proposal for the "one protocol will save the world" that the WG
had to step back and first create a taxonomy of building block to
sort through the necessary/beneficial functions in them and only after
that was done try to compose full-protocol recommendations.

Aka: would be lovely if this effort could lead to some useful taxonomy
of network conditions and components driving the innovations.

I am a bit cynical here, because if i look at the overall scope of
stuff going on (not specifically the ones proposed to be talked about),
what i see is this (yes, some pessimistic blinders used):

   60% workaround to get through NAT/FW with a transport flow
   10% workaround to get QoS without having QoS in the network
   10% workarounds to use multiple interfaces without having mobile IP
   10% workarounds to make new congestion control compete with the
       dumbest TCP stack and stupiest queue.
    9% workarounds to do transport stuff inside the app as opposed to
       traditionally the OS because OS stacks are also considered inagile.
    1% all the other cool stuff SCTP had already try to aggregate but
       re-done in the context of the above workarounds.

So, the evolution of transport protocols i see is this architecture:

 -> the network is a bunch of bad packet forwarders with a lot of NAT/FW,
    no DiffServ or other QoS, not even good AQM, no mobility, but a lot
    of congestion by badly behaving transport stacks.
 -> The OS likewise is not agile enough to deploy innovation.
 -> In-Middleware/App- Transport stacks to the rescue with all the above
    inside the transport stack, designed only against the lowest common
    denominator.

I totally get the business need that tranport stacks must do these workarounds,
even if it's just for the bottom 20% paths/subscribers of interest. But
what we have is overwhelmingly a focus on ONLY this bottom 20%, and little
in the transport stacks that balances expectations. If you bring in MUSTs
for workarounds at the bottom, i think the same spec MUST also include the
appropriate improvements for the top. Otherwise the market dynamics will
just continue to cause a race to the bottom and the title of the slot should
be:

 "Evolution of transport stacks - Rewarding bad networks and OS"

Cheers
    toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Matt Mathis <[email-masked]>
Date: Thu, 24 Oct 2013 13:11:29 -0700

Ok, so here is a slightly less cynical question: suppose you could map the
cruft at scale. What would you do with that information?

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.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 24 Oct 2013 23:33:34 +0200

Hi,

I should have cc'ed the group - I have asked Martin and Spencer to be able to contribute to this session, related to this effort:
https://sites.google.com/site/transportprotocolservices/
I think this is in line with your wish for a "step back" to create a taxonomy. It's not exactly that, and not focused on the network, but I think it's one necessary step if we want to make some real progress for the transport layer here.

Now, getting to what you want, as per what you write below, if you had an API that would be a little more abstract than saying "give me TCP please", then an OS or, heck, user-space "transport system" could just as well provide e.g. QoS *when it's there* underneath this API. Or it could use a protocol that doesn't require a lot of work-arounds in situations where they are not needed.

IMO the key is in getting the "best effort" notion represented in the API between the application and transport. It's not there now, and that's at least one reason why QoS for the broad Internet could never be brought to the application level, which is a problem that was already noticed in RFC2990.

Let applications say what they want, and let them live with the fact that in the worst case, they'll only get a normal TCP connection across the best-effort Internet, I say. I'll talk about that at the IAB ITAT workshop in December, see http://heim.ifi.uio.no/michawe//research/publications/iab-itat-workshop2013.pdf

... but incorporating stuff like that is a broader vision than the one in the Transport Services effort (which explicitly excludes QoS), and I don't think it would be wise to incorporate it there.

Cheers,
Michael

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Oct 2013 15:19:18 +0100

Toerless,

* QoS in the network is not unequivocally a good thing - for 
instance, if you can make delay predictably low for all BE traffic, 
you don't need or want the complexity of differentiated latency.
* Similarly, Mobile IP is not unequivocally a good thing.

Rest assured my slot will not be about the bottom 20%, it is about 
enabling a "top 20%" combination of AQM and transport (DCTCP) to be 
deployable alongside the bottom 20%, rather than stuck out of reach 
in data centres.

But, in general, I agree your point is true for many of these TSV 
efforts - and in a maturing network like the Internet you would 
expect that. However, universal damnation of everything wasn't warranted.

Bob

At 20:31 24/10/2013, Toerless Eckert wrote:
> > Possible to include HTTP? More and more applications run HTTP, 
> and many people believe that HTTP is the future of the transport protocol(s).
> >
> > Linda
> >

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Oct 2013 09:49:55 -0700

Very much in agreement with what you say.

Just wanted to help upleveling the discussion
from just the building blocks over to an analysis how the work we 
invest will help to raise the level of service also at L3/L2
(if/when appropriate/beneficial) and eliminate cruft there instead of
treating it like a protected species that is taking cycles away from
better solutions.

I think there is just a very logical barrier between infrastructure equipment 
mostly doing <=L3 and hosts primarily >=L4 and integration across that
barier is naturally focussed on working around what the other side does
badly instead of really pushing through good requirements against the other side.
And the higher layers, closer to te apps are just naturally in the stronger
position to make their desires happen, so it is most important that they
position themselves to raise the right requirements to the lower layers.

To not make it too long, let me just chime into your QoS point:

No strategic argument about latency. Just that its going to be IMHO a decade 
effort. A lot of CC unaware traffic will first go through a circuit breaker
stage and that traffic will still kill low latency.

But i primarily worry about bandwidth share. 

  - With just the likely CC/AQM work happening, we will just end up with
    "all flows can use no more than 3..5 times the bandwidth of other flows".
  
  - If that's not good enough, go figure out how to use DiffServ.

DiffServ sucks. Managing WFQ parameters is primarily an OSS job creation program.
We have no IETF solution/strategy to _easily_ build and enforce policies to 
differentiate BW allocation across traffic buckets/flows. 

Of course, this bitching here is self-serving, because IMHO the top
problem when going beyond "equal within 3..5 times BW" is to have
a framework to know more about the purpose and expectations of the
traffic buckets/flows at L3/L4 - see our framework doc ;-). Once we 
have this knowledge, we can start reasonably working out better
mechanisms for more appropriate policies.

Cheers
    Toerless

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Oct 2013 21:18:25 +0100

Hi Linda,

We have a full talk about QUIC which is not exactly HTTP but might get 
us some taste of the direction of HTTP.

However, if there are specific things to discuss, I am more than open to 
discuss them.

   Martin

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 29 Oct 2013 16:31:33 -0400

> However, if there are specific things to discuss, I am more than open to

If there's anything to discuss about HTTP, it would relate to its
needs from a transport protocol, as was done a bit at IETF87 and
on mailing lists afterwards.

HTTP itself isn't a transport protocol.  People run over it in order
to get through middleboxes and want to view it that way, but there are
still real transport protocols underneath it (TCP, QUIC, etc).

-- 
Wes Eddy
MTI Systems

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 29 Oct 2013 20:58:20 +0000

Here is my naive thinking of some improvement to be done at the transport layer for HTTP. I say naïve because it could be totally not feasible.  

More and more flows need to go through some additional functions (or treatment) based on HTTP header (e.g. HTTP request or reply). But the HTTP header is not fixed in the payload.  There could be multiple HTTP headers in one packet, or one HTTP message being carried by multiple packets. Therefore, it requires expensive DPI to filter packets with certain HTTP characteristics. 

It would make life easier for network equipment if the TCP header has a few bits to indicate the characteristics of HTTP message being carried. E.g. offset to the HTTP header, the number of HTTP message in the packet, etc. 

Linda

> From: Wesley Eddy [mailto:[email-masked]]
> Sent: Tuesday, October 29, 2013 3:32 PM
> To: Martin Stiemerling; Linda Dunbar; [email-masked]
> Subject: Re: Announcing the TSVAREA session on "Evolution of IETF
> Transport Protocols" @ IETF-88
>

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 31 Oct 2013 18:56:40 +0100

Hi Toerless,

> that was done try to compose full-protocol recommendations.

I don't see that we need one protocol that saves the world, but we might 
need to push some protocols forward or not.

> of network conditions and components driving the innovations.

That could be one possible outcome, as well as, that no changes are 
required.

>      of congestion by badly behaving transport stacks.

That's what we have by today.

>   -> The OS likewise is not agile enough to deploy innovation.

I'm not sure about this end, or it depends on how agile you are talking 
about. E.g., MPTCP seems to make it ways into OSes.

>      inside the transport stack, designed only against the lowest common

We hopefully do not need up there eventually, though there are movements 
towards this. This is one reason to make this session, i.e., are we 
doing right or are we missing something.

>   "Evolution of transport stacks - Rewarding bad networks and OS"

I agreed that we should not optimize for one fraction :)

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 31 Oct 2013 18:56:57 +0100

On 10/29/2013 09:58 PM, Linda Dunbar wrote:
> Here is my naive thinking of some improvement to be done at the
> transport layer for HTTP. I say naïve because it could be totally not
> feasible.
>
> More and more flows need to go through some additional functions (or
> treatment) based on HTTP header (e.g. HTTP request or reply). But the
> HTTP header is not fixed in the payload.  There could be multiple
> HTTP headers in one packet, or one HTTP message being carried by
> multiple packets. Therefore, it requires expensive DPI to filter
> packets with certain HTTP characteristics.
>
> It would make life easier for network equipment if the TCP header has
> a few bits to indicate the characteristics of HTTP message being
> carried. E.g. offset to the HTTP header, the number of HTTP message
> in the packet, etc.

I don't see any need to make TCP specific to HTTP.

   Martin

>
>
> Linda
>
>> -----Original Message----- From: Wesley Eddy
>> [mailto:[email-masked]] Sent: Tuesday, October 29, 2013 3:32
>> PM To: Martin Stiemerling; Linda Dunbar; [email-masked] Subject:
>> Re: Announcing the TSVAREA session on "Evolution of IETF Transport
>> Protocols" @ IETF-88
>>
>>> We have a full talk about QUIC which is not exactly HTTP but
>>> might
>> get
>>> However, if there are specific things to discuss, I am more than
>>> open
>> to
>>> discuss them.
>>>
>>
>>
>> needs from a transport protocol, as was done a bit at IETF87 and on
>> mailing lists afterwards.
>>
>> HTTP itself isn't a transport protocol.  People run over it in
>> order to get through middleboxes and want to view it that way, but
>> there are still real transport protocols underneath it (TCP, QUIC,
>> etc).
>>
>> -- Wes Eddy MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2013 11:08:29 -0700

> I don't see any need to make TCP specific to HTTP.

+1

Besides, DPI is meaningless as we shift to using HTTPS (as Google did 
since Sept 28, 2013).

Joe

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 31 Oct 2013 19:13:28 +0100

Hi all,

As promised a few more words about this part of the TSVAREA session in 
Vancouver:

The intention of this "Evolution of IETF Transport Protocols" part is to 
test the waters if the IETF transport protocols are 'on track' of what 
is needed by today's hosts and applications -- and what's happening in 
the network.

There are a number of activities around, see below, that propose changes 
to, for instance, TCP, and also new transport protocol proposals. There 
is also an on-going collaboration between the Transport Area and the 
HTTPbis working group with respect to HTTP/2.0.

We will tackle a few of the proposals in the session, but there is no 
restricition to those. Here they are in no particular order:

- The Saratoga protocol & interesting things out of this for the 
evolution of transport protocols (Presenter: Wes Eddy)
- Functional decomposition of the transport layer (Presenter: Jana Iyengar)
- TCP Crypt (Presenter: Andre Bittau)
- IETF-43 Requirements for Unicast Transport/Sessions (ruts) bof 
(Presenter: Spencer Dawkins)

Not well that there is also a presentation about the QUIC protocol just 
before this discussion.

Note even better:
The session does not need to deliver answers to any question that comes 
up, but is solely intended as a starting point for further activites, if 
needed, or just to note that we have talked about it, but everything is 
just fine and we can carry on.

Thank you,

   Martin

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Oct 2013 14:20:10 -0400

> - TCP Crypt (Presenter: Andre Bittau)

I laughed when I saw that.  I suggest "tcpcrypt" as a title instead.

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2013 11:33:47 -0700

Martin (et al.)

I continue to have grave concerns about additional presentations to the 
IETF by parties who squat on TCP option codepoints - in this case, TCP 
Crypt.

Any presentation on TCP Crypt to TSV should start - and end - with how 
they intend to undo the damage they have already done by deploying code 
using an unassigned codepoint.

I have raised this issue before, and it has still not been corrected:
https://github.com/sorbo/tcpcrypt/blob/master/kernel/linux/tcpcrypt/tcp_crypt.h

This situation needs to change before they should be given continued 
presence at the IETF IMO.

Joe

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 31 Oct 2013 19:50:20 +0100

On 10/31/2013 07:20 PM, Scott Brim wrote:
> On Thu, Oct 31, 2013 at 2:13 PM, Martin Stiemerling <[email-masked]
> <mailto:[email-masked]>> wrote:
>

oh yes, it should read tcpcrypt!
and also Andrea Bittau.

It's late over here...

Thanks :)

   Martin

---

From: <[email-masked]>
Date: Thu, 31 Oct 2013 23:44:56 +0000

You have grave concerns about crypt on Halloween?

And you already have a stake in this issue?

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: 31 October 2013 18:33
To: Martin Stiemerling; [email-masked]
Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport     Protocols" @ IETF-88

Martin (et al.)

Joe