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

[Bob Briscoe <[e-mail]>]

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:
>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
>
>
>On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar 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).
> >
> > Linda
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Martin Stiemerling
> > > Sent: Wednesday, October 23, 2013 2:13 AM
> > > To: [e-mail]
> > > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport
> > > Protocols" @ IETF-88
> > >
> > > 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 [e-mail] 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/
>
>--
>---
>Toerless Eckert, [e-mail]
>Cisco NSSTG Systems & Technology Architecture
>SDN: Let me play with the network, mommy!

________________________________________________________________
Bob Briscoe,                                                  BT