Minutes IETF104: iccrg
minutes-104-iccrg-00

ICCRG IETF 104 Prague - 28 March 2019
=====================================

(40 min) Neal Cardwell - An Update on BBR
-----------------------------------------

Ingemar (jabber): which RTT is it (on slide 6)

Neal: minrtt

Dave Täht (jabber): have you tried existing fq_codel response

Neal: We are bigger believers in a direction where ECN is like DCTCP or L4S,
where ECN responds at lower queue levels and sender has graduated proportional
response

Mar?: Which mechanism leads to convergence to fairness with many bbrv2 flows?

Neal: Depends on buffering. When buffer limited, we have multiplicative
decrease. When no buffer limit, convergence happens because of BW probing
dynamics. It's a little more subtle, but basically smaller flows' multiplicative
increase makes a larger proportional increase than the

John Border (Jabber): How do we always get a BBR response from YouTube?

Hiren: Drain phase is .. now, idea was getting rid of minrtt..?

Neal: To first approx if you can keep exactly bdp in flight then you get an
empty queue. You don't know the bdp, we cut down to half to eventually converge.

Hiren: Between 4 and 50%, rationale for 50% is because we're always doubling?

Neal: How far do we need to pull down the inflight, since people don't have
two-way prop delay estimate. Some amount to pulldown to compensate for
overestimate. 50% is based on tests

Praveen: Target loss rates: are you tuning them differently for different
workloads?  

Neal: Subject to tuning and research. Targeting loss rate around 1%. Threshold
for backoff during probing is 2%. Net effect is much lower than 2%, overall
average well below 1% 

Praveen: Reaction based on loss over time 

Neal: Once per RTT

Neal: 50% is 50% of estimated BDP

Michael Welzl: Are you negotiating AccECN?

Neal: Internal to Google we have private accurate ECN nego. Happy to work with
public efforts for a DCTCP-like mechanism. Externally, no standard for accurate
ECN, not using in public internet

Jake Holland: Also responding to RTT increase?

Neal: If you have inflight at ... [missing, please correct]

Andrew: ECN and lossrate targets as function of DSCP sent?

Neal: Talk offline.

Jonathan Morton: Would SCE be useful mechanism for ECN fidelity on BBR

Neal: Better than nothing, need finer-grained picture. More than one bit per RTT
is necessary


(25 min) Peyman Teymoori - Estimating an Additive Path Cost with Explicit
Congestion Notification
---------------------------------------------------------------------------

Jonathan Morton: ECN has low marking probabilites. DCTCP has deployment
properties. What about SCE? That gives you higher marking capabilities?

Peyman: Should work... [missing]

Bob Briscoe: Just pointed out on list a way to get additive property in
numberspace 0..1, you can change endhost to get p/1-p, i.e. number of marks over
number of unmarks, then you get additive property in a modified numberspace.

Michael Welzl: Calculation is done in the sender, otherwise regular red with 


(25 min) Bob Briscoe = Implementing the 'Prague Requirements' in TCP for L4S
----------------------------------------------------------------------------

Bob: Seems like we're converging on all the same pieces, BBRv2 is also using the
L4S style marking.

Dave Taht (jabber): For the mic. 1) It is a very good assumption that the CE
marks from "france" are due to free.fr's enormous (3+million) deployment of
fq_codel across their dsl subscriber lines. 2) Argentina, no idea, openwrt is
big there. 3) BBR currently caps cwnd reductions to 4, unlike reno.

17:31 as for point 1 - all someone looking at that data has to do, is pull out
the IP addresses related to free.fr's BGP AS number. That's it.

17:34 I don't know why that simple check of where the CE markings in france are
coming from is so hard.

Bob: Yeah we need to look at the CDN side

Praveen: Just loss in time units, are also packets?

Bob: If you pace IW you're implicitly working in time even with 3dupack.

Praveen: ECN capabable TCP control, on for DCTCP off for Prague, why?

Bob: Need fallback code, until then make it manual

Jonathan Morton: ECN is rare?

Bob: I think data showing ECN is rare, is wrong.

Andrew: you've looked at aggregated [max]?, especially for wifi cases

Richard: RACK has dupack rule, then you're shrinking reordering window in
time. Eventually rate goes high enough

Bob: Packets paced over RTT...


(25 min) Szilveszter Nadas and Balazs Varga - Multi timescale bandwidth profile
and its application for burst-aware fairness
-------------------------------------------------------------------------------

Michael Menth: this pursues similar goals to conex also apply to this approach

Jake Holland: this is going to be within a domain, doesn't need tuning, can pick
values for the matrix, for static demand, irrespective of downstream queueing
discipline...?

szilveszter: you do need to change things at the core, but it's open loop. in
this work, four precedences, other work 64k. 4 can be done with queueing config
in existing hardware

Bob: what michael said about ABC and conex, it doesn't need conex to do it,
since this happens at one node.

Szilveszter: All your core routers can take this into account

Bob: But it only uses local information at the sender

Michael: what you need for drop decision is local congestion information plus
packet value

Bob: As well as ABC there is a commercial implementation that [missing]
implemented, not published.