ICCRG Agenda - IETF 105 Date: July 23, 2019 (Tue), Session: Afternoon I Location: Viger Jana Iyengar asked a question to the room: New and important work is coming through ICCRG. Should we adopt and publish them through ICCRG? Brian Trammell, Google Do it. Michael Welzl, University of Oslo There is some resistance to publishing “useless IRTF documents”. Gorry Fairhurst, University of Aberdeen TSVWG chair What is the difference between publishing in ICCRG compared to taking work to TSVWG? Magnus Westerlund, Ericsson ICCRG is a good place for experimental documents. David Black, Dell EMC I agree with Magnus. This is where the deep expertise about congestion control exists. Jana Iyengar Are you saying we should publish this work here? David Black Yes, if you find that useful. Bob Briscoe, CableLabs ICCRG should be responsible for doing reviews of congestion control algorithms in transport protocols. Mirja Kühlewind, Ericsson Let’s not get stuck talking about process right now. Michael Scharf, Hochschule Esslingen, TCPM chair I disagree that ICCRG should publish documents about experimental congestion control algorithms. Congestion control work is in the charter for TCPM. Matthew Mathis, Google, Inc We’re really debating what it takes to put -iccrg- in a draft name. Colin Perkins, University of Glasgow Clearly congestion control work is in scope for ICCRG. -- (30 min) Neal Cardwell - An Update on BBR Gorry Fairhurst, University of Aberdeen Thanks for bringing this presentation here. This works looks like BBR is going in a good direction. I didn’t see any confidence intervals on the results. Neal Cardwell These are just early results. Gorry Fairhurst, University of Aberdeen Can you talk more about ECN in the high RTT experiments? Neal Cardwell The solution might be to have a response to ECN in the rate space. This might help avoid flows with high RTT being unfairly penalized. Martin Duke, F5 Networks, Inc. Are you going to write up a draft for BBRv2? Neal Cardwell Yes. Martin Duke, F5 Networks, Inc. Thanks. Having documentation is much better than just looking at the code. At low loss rates it looks like BBRv2 is 10% slower than BBRv1. Neal Cardwell This is intentional, to leave some capacity available for new flows. CUBIC has similar behavior, where it runs at 85% of the previous Wmax, to leave some capacity available for new flows. Jake Holland, Akamai What did you mean by L4S-style ECN marking? Neal Cardwell This is referring to ECN marking at fairly short queue lengths, plus receiver behavior that echoes back each individual CE mark instead of one mark per round-trip. -- (25 min) Marcelo Bagnulo Braun - rLEDBAT Jake Holland, Akamai This is very cool work, thank you. Neal Cardwell This is very interesting work. Is this done in a simulator? Marcelo Bagnulo Braun No, this is a real implementation Rachel Huang, Huawei How does this work with ECN? Mirja Kühlewind, Ericsson The idea of LEDBAT is to keep queues short, so there is no induced congestion -- (10 min) Praveen Balasubramaniam - LEDBAT++ Neal Cardwell, Google Why 60ms delay? Praveen Balasubramaniam Because of the default delayed ack time. Jake Holland, Akamai Why not use a dynamic delay value? Praveen Balasubramaniam We found that this value works in practice. Ian Swett, Google Can you make the delay configurable based on max ack delay? QUIC doesn’t mandate a 50 ms delayed ack time. Praveen Balasubramaniam That would be a good idea. Niklas Widell, Ericsson AB How does this work when there’s an AQM on the path? -- End