Re: [tsvwg] L4S and the RACK requirement

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

> I am missing something: how does DCTCP depend a specific loss
> detection mechanism (e.g. DupACK based, RACK, etc)? DCTCP is only
> mandated to react to packet losses.
> 
> Linux DCTCP uses RACK by default. There's no inherent dependency of
> the two either.

See slide 8 from Bob's Bangkok presentation to TCPM (and the rest of that
presentation) - the requirement in the ecn-l4s-id draft is more restrictive
than RACK as currently implemented - current DCTCP with RACK doesn't
meet that requirement.
 
https://datatracker.ietf.org/meeting/103/materials/slides-103-tcpm-sessa-l4s-rack-00

We (TSVWG chairs) are looking for "running code" ... as we're having difficulty
figuring out how the L4S experiment (the L4S drafts are intended to become
 experimental RFCs) would be carried out without any transport protocol code.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Yuchung Cheng
> Sent: Tuesday, February 12, 2019 7:27 PM
> To: Wesley Eddy
> Cc: [e-mail]
> Subject: Re: [tsvwg] L4S and the RACK requirement
> 
> 
> [EXTERNAL EMAIL]
> 
> On Tue, Feb 12, 2019 at 10:01 AM Wesley Eddy <[e-mail]>
> wrote:
> >
> > In discussion among the TSVWG chairs, we are concerned about lack of
> > consensus on the requirement currently in L4S ID draft (
> > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05 ) regarding
> > the need for RACK-like behavior in a transport that uses the L4S queue.
> >
> > The statement in the draft is:
> >
> >      A scalable congestion control MUST detect loss by counting in units
> > of time, which is scalable, and MUST NOT count in units of packets (as
> > in the 3 DupACK rule of traditional TCP), which is not scalable (see
> > Appendix A.1.7 for rationale).
> >
> > By saying this, it seems to rule out DCTCP and some other existing code
> > that might be used with L4S (and DCTCP discussed in the draft as an
> > example scalable transport, even though it violates this rule (?)).
> I am missing something: how does DCTCP depend a specific loss
> detection mechanism (e.g. DupACK based, RACK, etc)? DCTCP is only
> mandated to react to packet losses.
> 
> Linux DCTCP uses RACK by default. There's no inherent dependency of
> the two either.
> 
> > This seems like a bit of a problem for making L4S usable.  I guess maybe
> > TCP Prague code fixes this, but isn't as widely available yet?
> >
> > The discussion in the appendix is good at explaining what I think the
> > real goal is here, which is to enable major reduction in latency from
> > link-layer (or other underlying transport network) re-ordering buffers.
> > We want that in order to meet the low latency goals, which makes total
> > sense.
> >
> > So, my question is whether the "MUST" is really more appropriately
> > turned into a "SHOULD" guidance?  Given that we expect reordering to be
> > possible (and maybe normal) over hops supporting L4S, then the
> > congestion control algorithm SHOULD have mechanisms that allow it to
> > perform robustly.  If it doesn't, it only hurts itself, not any other
> > traffic, so there seems to be no real reason to say "MUST" (someone
> > violating it doesn't break the Internet or cause interop issues, etc).
> > As I understand it, this would allow the examples like DCTCP to be
> > relevant for use with L4S as well.
> >
> > Does Bob or anyone else have thoughts on this?
> >