Minutes IETF105: iccrg
minutes-105-iccrg-00

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