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

[Martin Stiemerling <[e-mail]>]

Hi Toerless,

On 10/24/2013 09:31 PM, Toerless Eckert wrote:
> 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.


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

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

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

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

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.

>   -> In-Middleware/App- Transport stacks to the rescue with all the above
>      inside the transport stack, designed only against the lowest common
>      denominator.

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.

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

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

   Martin