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

[Matt Mathis <[e-mail]>]

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.


On Thu, Oct 24, 2013 at 12:31 PM, Toerless Eckert <[e-mail]> 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!
>
>