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.