Re: [tsvwg] L4S and the RACK requirement

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

> Perhaps Bob can shed more lights on how TCP L4S would break badly w/o
> RACK?

Start by looking at the rest of that slide deck:

https://datatracker.ietf.org/meeting/103/materials/slides-103-tcpm-sessa-l4s-rack-00


Thanks, --David

> -----Original Message-----
> From: Yuchung Cheng [mailto:[e-mail]]
> Sent: Thursday, February 14, 2019 2:16 PM
> To: Black, David
> Cc: Wesley Eddy; [e-mail]
> Subject: Re: [tsvwg] L4S and the RACK requirement
> 
> 
> [EXTERNAL EMAIL]
> 
> On Tue, Feb 12, 2019 at 7:34 PM Black, David <[e-mail]> wrote:
> >
> > > 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 for the pointer. I too think RACK seems a recommended
> component, not a necessity based on the slides.
> 
> Perhaps Bob can shed more lights on how TCP L4S would break badly w/o
> RACK?
> 
> >
> > 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?
> > > >
> >