[Bloat] [tsvwg] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Holland, Jake]

On 2019-03-20, 12:40, "Gorry Fairhurst" <gorry at erg.abdn.ac.uk> wrote:
    Concerning "Maximize Throughput", if you don't need scalability to very 
    high rates, then is your requirement met by TCP-like semantics, as in 
    TCP with SACK/loss or even better TCP with ABE/ECT(0)?

[JH] A problem with TCP with BE/ECT(0) is that it gets at most 1 ECE signal
per round-trip, so the kind of high-fidelity congestion response I hope to
see out of some upcoming SCE-echo proposal would be very welcome, especially
in BBR (or similar), as well as anything that uses slow-start.

    I wonder .... if the intent is to scale to really high rates, then the 
    control loop delay for the congestion-controller becomes a limiting 
    issue, and in that case low-latency is necessary to safely climb the 
    rate to the high speed - and conversely to allow the controller to react 
    quickly when (or if) that overshoots a capacity bottleneck. In other 
    words, is scalable high throughput inseperable from low latency?

[JH] I agree lower latency, particularly including anything that avoids
buffer-bloat, is an important factor in returning a timely congestion
signal to the sender.

However, there may be a big difference in throughput between a CC that
allows for an increase of, say, 10-20ms, or +.5 base-RTT at a bottleneck,
vs. one that pushes back on anything above 1ms, especially when considering
paths with longer transit times.

In that sense of course a good bandwidth-maximizing approach benefits from
keeping latency low also, but perhaps with different thresholds.
    
    Gorry