[Bloat] [Cake] Control theory and congestion control

[Jonathan Morton]

> On 10 May, 2015, at 06:35, Dave Taht <dave.taht at gmail.com> wrote:
> 
> New flows tend to be extremely bursty - and new flows in the real
> world also tend to be pretty short, with 95% of all web traffic
> fitting into a single IW10.

There is some hope that HTTP/2 will reduce the prevalence of this characteristic.  It might take a while to reach full effect, due to how much sharding there is right now, but I’m mildly optimistic - it’s an application software change rather than at kernel level.  So there’ll be more flows spending more time in the congestion-avoidance state than in slow-start.

Meanwhile, I understand the reasons behind IW10, but it’s clear that pacing those packets according to the RTT measured during the TCP handshake is desirable.  That *does* need kernel support, but it has the fairly large benefit of not attempting to stuff ten packets into a buffer at the same time.  On drop-tail FIFOs, that inevitably leads to a spike in induced latency (more so if several flows start up in parallel) and a relatively high chance of burst loss, requiring retransmission of some of those packets anyway.

Aside from sch_fq, what support for TCP pacing is out there?

> If e2e we know we are being FQ´d…

In general, E2E we don’t know what’s in the middle unless we receive notice about it.  Or unless we’re in a lab.

 - Jonathan Morton