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

[Toerless Eckert <[e-mail]>]

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

On Fri, Oct 25, 2013 at 03:19:18PM +0100, Bob Briscoe wrote:
> 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