Subject: [iccrg] BBRv2 vs. Cubic (un)fairness "Who will Save the Internet from the Congestion Control Revolution?"

From: Szilveszter Nadas <[email-masked]>
Date: Wed, 11 Dec 2019 16:08:07 +0000

Hi ICCRG and BBR devs,

We presented our paper "Who will Save the Internet from the Congestion Control Revolution?" on the Workshop on Buffer Sizing last week. The paper shows that the drawback of the recent Congestion Control and Active Queue Management evolution is that if we combine all evolution in a heterogenous environment then flow fairness becomes quite bad. The solution is to use Resource Sharing Control, though that suffers from deployment issues.

paper: http://buffer-workshop.stanford.edu/papers/paper19.pdf
slides: http://buffer-workshop.stanford.edu/slides/who%20will%20save%20the%20internet.pptx
(all papers at the WS: http://buffer-workshop.stanford.edu/program/ )

Comments, proposal and discussion is welcome.

We plan to continue this experiment with e.g. higher speeds, more flows. We also welcome proposals on what more to study.

Some findings, copied from the presentation:

  *   High utilization in general, except for very small buffers (0.05-0.1 BDP) and small Number of flows
  *   AQM with Control of Resource Sharing (PPV) provides reasonable fairness in all cases
  *   Mono-CC fairness is good in most cases
     *   All except Mono-BBR with GSP

  *   Cubic vs. BBR fairness is very dependent on settings
     *   Depends on (common) RTT and  bottleneck capacity (100ms, 1 Gbps was the worst case)
     *   Depends on Buffer Size for TailDrop (this was the design target for BBRv2 Cubic compatibility)
     *   PIE and GSP usually do not help or hurt fairness
  *   Heterogenous RTTs (10 ms vs. 100 ms)
     *   PIE and GSP
        *   Improve fairness for mono-Cubic
        *   They decrease fairness in mono-BBR and mixed CC cases
     *   Mono-BBR fairness is interesting
        *   Higher share for low RTT flows for small buffers, for high RTT flows for longer buffers
        *   Different optimum (mid-sized buffer) than for Cubic (large buffer)

Cheers,
Szilveszter

Szilveszter Nádas
Senior Researcher
Ericsson Research, Traffic Lab
Budapest, Hungary