Hi, I should have cc'ed the group - I have asked Martin and Spencer to be able to contribute to this session, related to this effort: https://sites.google.com/site/transportprotocolservices/ I think this is in line with your wish for a "step back" to create a taxonomy. It's not exactly that, and not focused on the network, but I think it's one necessary step if we want to make some real progress for the transport layer here.
Now, getting to what you want, as per what you write below, if you had an API that would be a little more abstract than saying "give me TCP please", then an OS or, heck, user-space "transport system" could just as well provide e.g. QoS *when it's there* underneath this API. Or it could use a protocol that doesn't require a lot of work-arounds in situations where they are not needed. IMO the key is in getting the "best effort" notion represented in the API between the application and transport. It's not there now, and that's at least one reason why QoS for the broad Internet could never be brought to the application level, which is a problem that was already noticed in RFC2990. Let applications say what they want, and let them live with the fact that in the worst case, they'll only get a normal TCP connection across the best-effort Internet, I say. I'll talk about that at the IAB ITAT workshop in December, see http://heim.ifi.uio.no/michawe//research/publications/iab-itat-workshop2013.pdf ... but incorporating stuff like that is a broader vision than the one in the Transport Services effort (which explicitly excludes QoS), and I don't think it would be wise to incorporate it there. Cheers, Michael On 24. okt. 2013, at 21:31, Toerless Eckert <[email protected]> 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! >
