Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S

[Yuchung Cheng <[e-mail]>]

On Tue, Jul 9, 2019 at 8:41 AM Jonathan Morton <[e-mail]> wrote:
>
> > On 13 Jun, 2019, at 7:48 pm, Bob Briscoe <[e-mail]> wrote:
> >
> >       1.  It is quite unusual to experience queuing at more than one
> >           bottleneck on the same path (the available capacities have to
> >           be identical).
>
> Following up on David Black's comments, I'd just like to note that the above is not the true criterion for multiple sequential queuing.
>
> Many existing TCP senders are unpaced (aside from ack-clocking), including FreeBSD, resulting in potentially large line-rate bursts at the origin - especially during slow-start.  Even in congestion avoidance, each ack will trigger a closely spaced packet pair (or sometimes a triplet).  It is then easy to imagine, or to build a testbed containing, an arbitrarily long sequence of consecutively narrower links; upon entering each, the burst of packets will briefly collect in a queue and then be paced out at the new rate.
>
> TCP pacing does largely eliminate these bursts when implemented correctly.  However, Linux' pacing and IW is specifically (and apparently deliberately) set up to issue a 10-packet line-rate burst on startup.  This effect has shown up in SCE tests to the point where we had to patch this behaviour out of the sending kernel to prevent an instant exit from slow-start.
We (Google TCP folks) are internally experimenting (always) pacing IW.
May hurt very long RTT and short transfers (<=IW), but could be an
overall win.

>
>  - Jonathan Morton
>