> On 10 May, 2015, at 06:35, Dave Taht <dave.t...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
