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: [email protected] [mailto:[email protected]] On
> > Behalf Of Martin Stiemerling
> > Sent: Wednesday, October 23, 2013 2:13 AM
> > To: [email protected]
> > 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 [email protected] 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, [email protected]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!
________________________________________________________________
Bob Briscoe, BT
