2014-03-04 13:00-14:00 UTC IETF89, London TCMTF - Tunneling Compressed Multiplexed Traffic Flows - BoF Co-Chairs: Mirja Kuehlewind & Brian Trammell Many thanks to Alan Ford and Sebastian Kiesel for taking notes! Goal: optimise services using small packets, e.g. VoIP, online games, etc (time-sensitive), and non-delay sensitive (sensors, IM, etc). Packets are muxed and headers compressed at TCM ingress, and demuxed at egress. TCP CC governed by RTT, so may reduce throughput: however, not the main use case. Acceptable delays for RT traffic are given in recommendations draft. TCP now out of scope. About 75 participants in the room. Comments ======== Stuart Cheshire: More apps have persistent keepalives (IM etc). Multiplexing persistent idle connections to keep one FW state live, but is this out of scope? Yes TCP is out of scope Jose: considered but decided to use this just for real-time. Alexander Harrowell: There is a need for this, especially for small cells and rural environments. Strongly support for the need for this. Exclusion of TCP worrying and will limit utility. Colin Perkins: We have RFC4170 and tunnel compressed RTP. Is this anything larger than optimising other protocols into 4170 framework? Jose: many uses such as sensor networks. Colin: Not disagreeing with leaving out TCP. But TCMRTP handles plain RTP flows just fine. Jose: idea is to standardise protocol stack, recommendations, and negotiation protocol, so that multiple vendors can interop. Dan Wing: As coauthor of 4170: at the time it was simple, lets layer technology (compression, multiplex with PPPMux, tunnel over L2TP). Much thinner and easier solution desired. How to negotiate maximum tolerance for delay/jitter is needed. Dirk Kutscher: do we need a negotiation protocol? Jose: yes Dirk: SIP already provides such negotiation features. can we reuse? Jose: didn't think about negotiation in detail Lars Eggert: Wondering about senarios. Need a path where this makes the difference between an overloaded and underloaded. But competing with TCP will mean that TCP will just eat it up at the cost of added delay and more boxes. Mirja: If you have to pay for bw, e.g. satellite, this is useful. Diego: There are scenarios where bw is more expensive or even not available. E.g. rural/Africa. Mirja: delay is sometimes not the most important thing (e.g. 450 jump to 470ms) Chunshan Xiong: Different traffic types have different priorities etc, so he uses DSCP to model prioritisation in the path. Jose: is it sensible to put different quality in the same packet? Not so much - classify into packets of the same service. CX: But that decreases bw benefit. Gorry Fairhurst: Disagree with Lars. If fighting with a TCP flow you’re going to have some management anyway (in the case of satellite etc). Do we have buy-in from small satellite accelerator etc boxes? Brian: Any vendors of these in the room? (no hands) Michael Ramalho: This is a real issue and doesn’t see the TCP one as such a big deal. Martin Stiemerling (as individual): Extremely long backhaul links, thousands of people on 2Mbps. These users could benefit if TCP was shaped and reserved something for this. Martin Stiemerling (as AD): after Berlin IETF I received many mails from participants from Africa supporting this activity. Dirk Kutscher: Most of these links are in single operational domains, is there any need for a standardised protocol? Dan Wing: Yes, allow multiple vendors to compete. And allow other suppliers in different countries. E.g. much traffic from British Telecom to Electronic Arts (World of Warcraft). We don't want that both have to buy equipment from same vendor Lars: gamers care about single milliseconds of delay, so if anything was added they’d move. If you’re not doing TCP in this, there isn’t a lot of point of this, given there are very few UDP in comparison to TCP. Spend the money on fibre not magic boxes. Jose: community networks is another use case. Running wifi links between lots of small villages, not a lot of bandwidth. Lars: Isn't most of the traffic TCP? Brian: Hear a crucial dependency on traffic mix. Need to apply this only to traffic that this has an effect on. Christian Koenning: What traffic do you see being optimised? Gamers don’t play games over satellite links. DNS maybe? (But how much can really be muxed here?) This seems to be a scientific problem searching for use cases. Mirja: there are these boxes already deployed. So there seems to be a need. But do we need to standardize? Tim Chown: What are the typical applications? At the moment the charter only talks about architecture not applications. Benefit for interoperability. Not hearing any feedback from builders of these boxes. Why does the charter list the old 4170 protocols? Not any clear improvement on 4170. Brian: We should be backward compatible, this should be noted. Michael Ramallo: this is another source for RTT noise. but lower layers might add much more variation. is this understood? Not only TCP does delay-based congestion control. Need to define harm of additional delay. Tim Chown: incremental deployability is a useful thing in the charter which may back up the backward compatible one. Jose: backward compatible is one possible branch of the stack. Spenser: TAPS is relevant here, allow apps to say what they need. Tim: You want to say what you can do with the free bw. Brian: We need an applicability statement. Nalini Elkins: DTN networks do a lot of buffering (for developing countries and satellites etc). Quite a number of flows are insensitive to delay. Broad category of non-delay-sensitive. Dave Oran: If the boxes in the market also do TCP, then we’re not really solving the problem here. Dan: there are many more features you can turn on on any box. Questions ========= Is this a solvable problem? Response was positive. Many hands yes, few hands no. Is trying to standardise this futile? Lars thinks so. Do we need to standardise a solution in the IETF? 15-20 hands Not worth it? 8-10 hands. No clear consensus in the room on bringing work into IETF. If we’re going to standardise do we start from here? 12-15 hands yes, 1 no. Is the problem well defined and scoped? 12 yes, 4-5 no Martin (as AD): If this work is to be done we should have a small well-scoped WG. Who will work on drafts here? ~8 (incl. 3 current authors) Martin (as AD): there are definitely others who are interested who are not in the room.