Re: [tsvwg] David Black (individual) on safety of L4S for the Internet

["Black, David" <[e-mail]>]

[still as an individual]

> I can't parse the logic of
> 
> 1) L4S / TCP-prague can have implementation bugs/violations that cause
> ECT(1) to be disabled/ignored forever, hence fq+bleaching would make
> it safe.
> 2) QUIC uses Reno so it's safe

The two mechanisms (Prague and Reno) are at very different stages of maturity.  There is a lot of deployment and operational experience with Reno, which is a proven mechanism at this juncture,  whereas Prague is brand new research.  In time I hope/expect to see Prague become as mature and solid as Reno, but the two are at rather different states of maturity now.

> What prevents these "safety" mechanisms from having bugs too? I have
> seen vendor fq implementations that're really not fq at all. QUIC
> senders can in reality run any congestion control they like.

Nothing prevents that - bugs are inevitable ;-), but with a well-understood mechanism like Reno with which there is a lot of experience, it's obvious that a bug is a bug.  There's still much to be learned about Prague, so "interesting" behavior may be a bug, an opportunity to better tune the heuristic or maybe even a feature.  Experimenting with Prague to better understand it is a good thing, but something else ought to be providing protection from the experiment going off the rails.  That something else doesn't have to be FQ+bleaching.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Yuchung Cheng
> Sent: Friday, May 8, 2020 7:00 PM
> To: Jonathan Morton
> Cc: Neal Cardwell; [e-mail]
> Subject: Re: [tsvwg] David Black (individual) on safety of L4S for the Internet
> 
> 
> [EXTERNAL EMAIL]
> 
> I can't parse the logic of
> 
> 1) L4S / TCP-prague can have implementation bugs/violations that cause
> ECT(1) to be disabled/ignored forever, hence fq+bleaching would make
> it safe.
> 2) QUIC uses Reno so it's safe
> 
> What prevents these "safety" mechanisms from having bugs too? I have
> seen vendor fq implementations that're really not fq at all. QUIC
> senders can in reality run any congestion control they like.
> 
> 
> On Fri, May 8, 2020 at 3:38 PM Jonathan Morton <[e-mail]>
> wrote:
> >
> > > On 9 May, 2020, at 1:04 am, Neal Cardwell
> <ncardwell=[e-mail]> wrote:
> > >
> > >> Current practice is not to mix DCTCP-like traffic (1/p-class congestion
> > >> control) with TCP-like traffic (1/sqrt(p)-class congestion control, e.g.,
> > >> NewReno) in the same queue because the DCTCP-like traffic outcompetes
> the
> > >> TCP-like traffic to the point of starvation of the latter.
> > >
> > > For my education, does someone have a pointer to the experiments
> > > underlying that description of DCTCP outcompeting Reno/CUBIC? I'm not
> > > aware of that being a fundamental property of DCTCP. The DCTCP
> > > algorithm specifies a Reno-style response to loss -
> > > https://tools.ietf.org/html/rfc8257#section-3.5 - and has Reno-style
> > > increase functions as well. So the algorithm should be Reno friendly,
> > > AFAIK.
> >
> > The problem with DCTCP is not its response to loss, though there was a
> serious bug that apparently went unnoticed for a long time.  Rather, it has to do
> with the response to CE marks applied by an AQM.  We can analyse this
> qualitatively and show a clear difference which will always result in severe
> unfairness.  This is also easy to confirm by experiment.
> >
> > Assume that a single queue exists at the bottleneck, with a single ECN AQM
> which does not discriminate between flows and classes of traffic.  This queue
> and AQM are shared by diverse traffic flows, some of which adhere to RFC3168
> and RFC-8511, some of which are Not-ECT, and some of which are DCTCP..  The
> Not-ECT packets will, in accordance with RFC-3168, be dropped if they would
> have been marked CE.
> >
> > The steady state for both Not-ECT and RFC-3168/8511 transports (which
> include NewReno and CUBIC) is multiple RTTs between CE marks.  Each round-
> trip containing a CE mark (or a packet loss) causes a Multiplicative Decrease to
> between 50% and 85% of the previous congestion window, as defined by RFC-
> 8511 and earlier well-known specifications.  It then takes several RTTs to grow
> the congestion window to its previous value, where a further congestion signal
> can be expected.
> >
> > The steady state for DCTCP is two CE marks per round-trip.  Each CE mark
> causes half a segment to be subtracted from the congestion window, on
> average.  This is qualitatively different from the response specified by RFC-
> 8511.  In particular, to obtain the 50% reduction to a single CE mark that
> NewReno implements, an entire congestion window's worth of segments must
> be marked CE by the AQM.
> >
> > Two results should be obvious from the above.  First, an AQM response that
> causes RFC-8511 compliant transports to back off substantially may cause very
> little response from DCTCP.  Second, an AQM response that produces the
> steady state in DCTCP will also apply CE marks (or packet loss) to almost every
> round-trip of other competing flows, which will cause conventional TCPs'
> congestion windows to collapse to very small values.
> >
> > That is why DCTCP is specified for deployment only in controlled
> environments where its interactions with conventional TCP can be strictly
> managed.
> >
> >  - Jonathan Morton
> >