ICCRG meeting, IETF 100, Singapore Monday 13. November, 13:30-15:30, Collyer Chair update: Thanks to reviewers of draft-barik-mptcp-lisa-01. Feedback was useful, authors plan to incorporate it in the future, as they plan to integrate draft-barik-mptcp-lisa-01 in the next version of draft-welzl-tcp-ccc-00. Part 1: BBR - evaluation and update ----------------------------------- Nicolas Kuhn: "MPTCP and BBR performance over SATCOM links" (15 min) Nicolas going through myths and non-myths to arrive at the evaluation of BBR over SATCOM. Also tested MPTCP proxies to improve performance. See conclusions in slide set. Yoshifumi Nishida: An interesting experiment with MPTCP. If we are going to duplicate, do we need more information than in the slides? Nicolas: Yes, everything is on the slides Roland Bless: "An Experimental Evaluation of BBR Congestion Control" (20 min) Presenting a paper published last month at ICNP. Sevaral findings. 1. Bottleneck model is fine, but as used in sender do not consider multiple flows. Multiple flows increases the overcapacity data. In cases of smaller buffers it results in losses. For large buffers which can fit 1-1.5 BDP the link latency is not optimized. 2. Interprotocol fairnes. Multiple BBR flows are very aggressive and a late coming CUBIC flow gets very small portions of bandwidth. 3. RTT Unfairness for large buffers. Loss of response to packet loss. Stuart Cheshire: As the cap is based on RTT and delay, thus continuously filled buffer should result in growing buffers as the BDP estimate grows. Have the experiments shown this? Roland: Some, in the intial phases of a flow but it stabalizes. Geoff Houston: Test London Frankfurt stabilized at 50% packet loss at 300 mb. No other traffic managed to get in. Gets to full queue point and just stays there. Janardhan Iyengar: As the calculation of the BDP uses minimal RTT the inflation doesn't really happen. Neal Cardwell: "A quick BBR update: BBR in shallow buffers" (10 min, remote) Reviewing main points why BBR v1.0 looks like its does. Current work on improving BBR to address several shortcommings. See slides and recording. Bob Briscoe: No evidence that packet loss is not a good estimator for congestion. Started using it, but not really gone into it. Neal: Deep buffer delays the indicator. In switches with short buffers (1-2 ms) and where flow has large RT, there can be occasional congestion events that are very short. This could result in significant underutilization. Bob: BBR is pushing the buffer occupancy instead of trying to go slightly below capacity. Neal: True for BBR1, addressing this. Andrew McGregor: Switches as well as WIFI are good example of poor congestion indicators of loss. Mirja Kuhlewind: 5% loss as threshold is that really solving the issue. Neal: Looking at tuning what are the right intervals between loss events that probing should result in. Mirja: For data centers there is simpler solution called ECN. Stuart: If it is true that loss just randomly happens, what do we do about them? Do we improve buffers and WIFI algorithms to reduce random loss, or do we just say no, lets just power through the loss? IF all clients would push forward then the goodput would be very low with massive waste of resources. Every packet that doesn't make to the destination wastes resources, battery power, etc. Neal: Yes, BBR v1 has issues. We are absolutely taking this head-on. As you heard, in BBR v2 the loss signal will explicitly factored into the algorithm in several ways: estimating whether pipe is full; deciding how BBR backs off; deciding how long to stay backed off. With BBR v2 hopefully you'll see something more to your liking. Part 2: Others -------------- Roland Bless: "TCP LoLa - Toward Congestion Control for Low Latencies and High Throughput" (20 min) Investigating how far we can get with congestion control and AQM in wide area networks. Mirja: I like the fair flow balancing. May be able to improve by minimal RTT measurement. David Hayes: "Congestion metacontrol to achieve a deadline aware less than best effort service" (20 min) No Questions. Praveen Balasubramanian: "LEDBAT++: Low priority TCP Congestion Control in Windows" (20 min) Jana: What is the increase? The one-way half of the RTT measurement Michael Sharf: A draft could be processed in TCPM. TCPM would send it to ICCRG. Gorry Fairhurst: TSVWG is the other possibility. Jana: We (ICCRG) will fight for it. The improvements are both for generally improving the algorithm. Some parts are more about how LEDBAT is used in TCP. Lars Eggert: LEDBAT RFC is a experimental IETF track RFC. Considering that Ledbat is used, taking on improvements is good. But, maybe time for a standards track RFC. The split Jana suggests is a good idea. Spencer Dawkins: Another thing to consider who else in the IETF will see it? Have you worked it through already? Praveen: We've not solved AQM Spencer: If there's still research to be done, it would make sense to do it where research is being done. Lin Han: "Thinking of transport to support ultra-high bandwidth and/or ultra-low latency applications" draft-han-6man-in-band-signaling-for-transport-qos-00.txt (15 min) Only got to do a short pitch for this. Will be discussed in TSVWG on Friday.