Re: [tsvwg] L4S and the RACK requirement

[Bob Briscoe <[e-mail]>]

David, Richard, Yuchung, all,

1/ Let me explain why I would still argue for MUST, even tho it strictly 
rules out existing DCTCP (cos of its initial use of 3DupACK).

Existing DCTCP does not comply with other requirements in the draft 
either. The requirements started life as a list of things to change in 
DCTCP. DCTCP has always been put forward as an interim solution that is 
sufficiently close to the requirements that it can be used for initial 
testing / demonstration.

The draft is experimental track. It states how the code of all L4S 
senders has to behave if you want to get meaningful results from an 
experiment. For an experimental draft, I would argue against saying "You 
SHOULD do X", if actually you MUST do X before you can expect to get the 
results claimed by the draft.

2/ To coexist safely with other Internet traffic?

Nonetheless, this discussion has helped me see a deeper problem with 
this list of L4S congestion control requirements. I think this is the 
root cause of David's concern.

The time-units requirement is about inter-operability with any links 
that do not maintain strict ordering. It is not about safe co-existence 
with other traffic. That's true for some of the other requirements too. 
So I propose that we split up the list into:

  * those requirements that really are about safe coexistence with other
    traffic
  * those requirements that are about interoperability with other parts
    of the L4S experiment (where safety is too strong a word)

Then code that does not meet any safety requirement cannot be used 
safely on the public Internet. Whereas code that doesn't interoperate 
with the rest of the L4S experiment can still be used on the Internet, 
it just won't necessarily give meaningful results in an L4S experiment.

For instance "MUST react to packet loss in a way that will coexist 
safely with a TCP Reno" is a safety requirement. So a DCTCP that does 
not satisfy this requirement cannot safely be used on the Internet For 
instance, Windows DCTCP is safe on the public Internet, but current 
mainline Linux DCTCP is not because there's bug where it intends to fall 
back to Reno - here's Koen's patch 
<https://www.spinics.net/lists/netdev/msg420916.html> from 2yrs ago.



Additional responses (to Richard) tagged [BB] inline...



On 15/02/2019 16:20, Scheffenegger, Richard wrote:
>
> 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?
[BB] If an approach implicitly uses time, surely that satisfies a 
requirement to use units of time?

>
>
> Also, for the proposed RTT/8, what would be a default starting value 
> for RACK? 1 sec / 8 = 125 ms?
[BB] No, I suggest:

(initial RTT from the 3WHS) / 8

Depending on the implementation, the RTT smoothing algo sometimes 
bootstraps using prior info as well, such as per-destination cache or 
TFO cookie.

Cheers


Bob

>
>
> 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?
>>>>>>
>>>>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/