Re: [tsvwg] L4S and the RACK requirement

["Scheffenegger, Richard" <[e-mail]>]

OTOH, for non-RACK (time-based) stacks, mechanisms like this
https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02

should also adjust to the reordering extent - the current wording of L4S 
seems to preclude any enhancement along those lines to qualify for use 
of L4S, even thoug a dynamic measurement of the reordering extent would 
implicitly have some time component as measured, correct?


Also, for the proposed RTT/8, what would be a default starting value for 
RACK? 1 sec / 8 = 125 ms?


Best regards,
   Richard

Am 14.02.2019 um 21:18 schrieb Black, David:
>> 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?
>>>>>
>>>