TCMTF BoF @ IETF 87 (Berlin, Germany) Chairs: Gorry Fairhurst Janardhan Iyengar Responsible AD: Martin Stiemerling Note Taker: Wes Eddy TCM-TF Problem Statement Dan Wing introduced the problem statement - The focus is on tiny packets, and sensitive to delay. - Instant messaging, M2M, sensor networks are not delay sensitive, but use small packets. - The goal is to compress & multiplex small packet flows to save capacity and reduce the packet per second rate. - A set of different scenarios were discussed (residential/gaming, corporate/VoIP, M2M+satcom), identifying the need for dynamic compression, e.g., to reduce the packets per second (PPS) by exchanging CPU resource for network bandwidth. - He discussed how TCM-TF improves on previous TCRTP, standardised in 2005. Thomas Narten: How widely was TCRTP deployed? Answer: I am not aware of much deployment of TCRTP. - The problem still exists, Cisco has proprietary things that they do; e.g., these work well for satellite, customers like them. - It reduces PPS and requires similar devices on both ends of a link. - A standard that could operate between vendors is desirable. - It was discussed why transport area is most appropriate. - having a separate WG can improve focus vs doing work in TSVWG. Lars Eggert: The use-cases mentioned TCP, TCP has an ACK clock that paces segments in the network. There is at least a potential here to create packet bursts. Is this problem being addressed, or is there experience to help in this space. Dan: That is why we have come to the transport area for guidance, so we can run this over the Internet and get this review of how to work with TCP, RMCAT, etc. We are looking to make recommendations in this space. Ramki Krishnan: Are we multiplexing packets of the same flow? Dan: Do you mean do we always multiplex packets from a flow? Rami: No. I mean do the packets belong to a single flow? Dan: This is usually multiplexing packets from different flows that are going towards the same place (see slide 6). It is destination-based multiplexing, but by configuration of destinations for the tunnel (a route map), not per IP address. Rami: This does not do flow learning. Dan: Yes, e.g. it could use an ACL to match a set of filters to place it in the tunnel/. Jabber question: There was mention that you could use this to optimise performance. Can you leave it on all the time? Dan: That may not be the most useful - it consumes router CPU resource. Spencer Dawkins: Would people be happy if we chartered work the work to only using RTP? Dan: Some would, some would not - this depends on the user traffic. Stuart Cheshire: We could turn this on reactively when a queue builds up, to accelerate packets. This could avoid configuration and come into play when packets are queued. Dan: Yes, others have talked about doing this to reduce the queue. Chunshan X.: Does it apply to SRTP? Dan: Yes. These are indistinguishable on the wire. TCM-TF Reference Model and Stack Jose Saldana discussed reference model and stack - Different protocol payloads (TCP, UDP, RTP) are possible - Different compression algorithms are possible - The BoF is only considering PPPmux now for muxing, but others are possible. - Sifferent tunnelling possible (L2TPv3, GRE, MPLS). - The plan is to be backwards compatible with TCRTP. - The bandwidth savings are higher for small IPv6 packets. - Showed many examples of savings in PPS and b/w for different types of flows. Lars Eggert: Is compression guaranteed to reproduce packets exactly? Is this bit-wise transparent to ECN, DSCP? Answer: Yes. Lars: This also applies to packet headers? Answer: Yes. Chunshan: It needs to know where packets start and end. Answer: PPPmux does this work. Chunshan: Is there a UDP checksum validation? Answer: The checksum is kept, you can remove fields that are the same for every packet, not that vary and can not be predicted (like the checksum). Jabber: Does compression see identical packets to many players? Answer: Games do not send every player identical information; only each gamer's area of interest. Gorry: Does this work with multicast packets? Do you plan to look at this? Answer: This has not been considered. TCM-TF Recommendations Mirko Suznjevic talked about recommendations (delay limits and policies) - Adding delay may delay QoE for some services, and needs policies to configure this. - TCMTF should maintain or increase the QoE, preventing loss or increasing availability, without ruining QoE. - It needs to detect flows that are candidates for optimisation. - Multiplexing is the main source of delay. - Policies can be based on various parameters: the number of packets, timeout, period, or size limit. - The suggested delay recommendations depend on the service. R. Peon: With switch-based games, 15ms is not visible to a user but could impact the experience. R. Peon: This is not being done by a host; it is in network, if a separator does not include timing, it could lose delay signals for congestion control based on delay. B. Briscoe: The wrong question is being asked; not what is tolerable, intend it should be what people "want". J. Saldana: For First Person Shooter games, the acceptable delay depends on the game. Mirko: This is not about the specific numbers. Lars: Even though this may only increase the round-trip a little bit, TCP performance depends on RTT, and can be impacted. Overview of Proposed Charter Diego Lopez described the charter - It is not intended to invent new protocols; It defines a framework for existing ones. - The core documents are: - reference model. - negotiation protocol. - analyze effects, make recommendations, etc. - There is potential for additional work: discovery, security, additional application use cases. Discussion of Way Forward The chairs showed the draft charter on the slides with proposed milestones. Le Zhu: What is the effect of packet loss on this? Answer: This is not end-to-end. The loss impacts all encapsulated packets and applications retransmit the lost packets. Margaret Wasserman: Is there congestion control on the tunnel? All flows with a packet in the new packet could backoff; There are also problems with fragmenting and defragmenting in the network -- The unit of loss and retransmission has to be the same; you could write a protocol where not all packets are lost if one is damaged. R. Peon: I have deployed a protocol that does multiplexing and compression and appreciate the problem area, and also terminate a lot of connections for users. The TCP Nagle algorithm adds ms of latency and has costs; sometimes small packets are sent for a purpose (e.g. because information is time sensitive); I am concerned with how this interacts with anything that looks at inter-packet delays -- Google has attempts to make download results really small caused the TCP window to not open up quickly and hurt performance. We need to be extremely careful when we look at TCP. I can understand a need for this in extremely limited circumstances for links at capacity. R. Peon thinks there is a need for this is in extremely limited cases and that it should be a fallback for when link is at capacity; It could be detrimental. L. Eggert: I have similar reservations, global synchronization (e.g. following multiple TCP loss) from a single tunnel are going to be bad; I am not sure this is safe for TCP and whether this applies to future methods such as RMCAT. The broadening of scope worries me. Al Morton: I can see the need where link capacity is an issue; I did not see the notion of tunnel heartbeats to know if the tunnel itself goes down or revert to a native mode for a while. Gorry: Perhaps we should also look at PMTU issues? Al: Yes. The operations considerations should be thought about. Bob Briscoe: I share concerns about the implications on congestion control; it may be possible to prove this is fine, but it looks worrying; I am concerned about adding latency and complexity to save relatively little bandwidth - when there will be a need for checking the network path. Bob Briscoe: Do vendors want standards in this space? There are a lot of proprietary products; I would like to hear from other vendors who also would like to see this. Gorry asked for people who might use or implement to come forward. Tim Chown: There is probably a use case for satellite, but not sure otherwise. M. Ramalho (Cisco): This may not be that harmful to CC, but this should be looked at; error multiplication should be studied, soon lots of devices will be everywhere sending small packets and delay may not be important; I encourage this work to go forward for that day when there are lots of little flows and they may have very different properties to other flows; the value of this work may come later and this is an opportunity to get in front of that! Jose S.: Regarding added delay, some users could be harmed -- UDP delay can be acceptable to save bandwidth; for TCP - talking about application-limited flows; regarding costs, there are situations (release of a game, rush hour, team scores goal) if the network does not work, it's also cost, for a player having a small delay is better than not playing! jabber: M Richardson, as a business VoIP provider, I want to reduce PPS, but this does not need a middlebox, it needs an IETF standard, bufferbloat at edges is in the way rather than core bandwidth. Tim Chown: The statistics shown at the tsvarea for gaming traffic was a small percentage, so optimizing that does not seem like a big issue; bufferbloat - could be increasing buffers to group packets up. Gorry: Counting per packet or bytes matters. R. Peon: A different MSS could cause bufferbloat; application can sometimes send multiple packets with the same message so that they have unique probability of loss (not correlated), this is an application choice that needs to be known by a tunnel. Jana: Compression in this case can happen among multiple flows (but does not always have to be done). Chunshan: These issues need to be fixed in the negotiation protocol, Jose: There are very different actors that can be doing optimization (end user, ISP); some companies selling middleboxes are doing bad things, we will not do these, and need to specify the right way to do the compression. Lars: I have a question about ways to make this safer for TCP; you could burn more CPU to re-instate spacing, if you avoid bunching packets that are not already in a queue you can avoid delay, etc. ... in my mind this is a tradeoff, it can be worth it, but how much CPU is worth this? Jana: Does anyone have operational experience with this type of device? How does multiplexing impact user traffic? (postponed to mailing list -- short on time) Chairs asked for feedback on some questions: Is the problem statement clear and solvable? (Many hands) Is it not clear? (Some) - Margaret: The scope needs to be refined. There are additional issues that need to be covered - that is why some people raised hands. Are people willing to review docs or comment on mailing list? (Many hands). Given an update to the charter and scope, should a WG be formed to work on this topic, please hum now? (Some hums) Who does NOT think work should be done? (some hums) The chairs reported hums in both directions. Are there people who think a working group should NOT be formed at this time? (some hands) The decision about what to do now goes to the AD. Chairs: Please continue the discussion on the mailing list.