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
