Re: [tsvwg] Review comments on a careful read of the L4S ID (#8. DCTCP)

[Bob Briscoe <[e-mail]>]

Gorry,

On 14/05/2021 09:55, Gorry Fairhurst wrote:
> On 13/05/2021 23:13, Bob Briscoe wrote:
>> Gorry,
>>
>> Please advise whether the following edits address this concern.
>>
>> See [BB]
>>
>> On 06/05/2021 07:52, Gorry Fairhurst wrote:
>>>
>>> =================================================================
>>> *8. Please be clear throughout that the IETF is NOT endorsing DCTCP 
>>> spec. as an Internet Protocol, even if the underlying basis is 
>>> important to the L4S transport.*
>>>
>>> This text:
>>> “An example of a scalable congestion control that would enable the L4S
>>> service is Data Center TCP (DCTCP), _which until now has been_
>>> applicable solely to controlled environments like data centres
>>> [RFC8257], because it is too aggressive to co-exist with existing
>>> TCP-Reno-friendly traffic. “
>>
>> [BB] PROPOSED:
>>    L4S relies on 'scalable' congestion controls for these delay
>>     properties and for preserving low delay as flow rate scales, hence
>>     the name.  The congestion control used in Data Center TCP (DCTCP) is
>>     an example of a scalable congestion control, but DCTCP is applicable
>>     solely to controlled environments like data centres [RFC8257],
>>     because it is too aggressive to co-exist with existing TCP-Reno-
>>     friendly traffic.
>>
> [GF] Perhaps on thinking more... maybe it would be better to say:
>
> /it is/the current specification is/
>
> ... I've no idea if the DCTCP spec will in future be updated.
>

[BB] Doesn't that introduce more doubt, whereas you wanted unambiguous 
clarity (and CC designs don't tend to become less aggressive anyway)?

>>
>>> and later:
>>> “Note that a transport such as DCTCP is
>>> still not safe to deploy on the Internet _unless it satisfies the_
>>> _requirements listed in Section _4.”
>>
>> [BB] PROPOSED:
>>
>>    Note that a scalable congestion
>>    control is still not safe to deploy on the Internet unless it
>>    satisfies the requirements listed in Section 4.
>>
> [GF] Looks good.
>>> and later still:
>>> “cause Classic ECN
>>> congestion controls sharing the same queue to starve themselves,
>>> which is why they have been confined to private data centres or
>>> research testbeds_(until now)_.”
>>
>> [BB] PROPOSED:
>>
>>     outcompete Classic ECN congestion controls
>>     sharing the same queue, which is why they have been confined to
>>     private data centres or research testbeds.
>>
> [GF] OK
>>> and
>>> “It turns out that a congestion control algorithm like DCTCP that
>>> _solves_ the latency problem also _solves_ the scalability problem of
>>> Classic congestion controls.”
>>
>> [BB] PROPOSED:
>>     It turns out that these scalable congestion control algorithms that
>>     solve the latency problem also solve the scalability problem of
>>     Classic congestion controls.
>>
> [GF] I'd prefer to change: /also solve/ or /also can solve/ ... but 
> this isn't important to me.

[BB2] OK.

>>> and
>>> “The L4S service is
>>> for more general traffic _than just_ DCTCP--“
>>
>> [BB] Substituted 'TCP Prague'
>>
> [GF] OK
>>> The ID later states:
>>> “As with all transport behaviours, a detailed specification 
>>> (probablyan experimental RFC) will need to be defined for each 
>>> congestion
>>> control, following the guidelines for specifying new congestion
>>> control algorithms in [RFC5033].”
>>
>> [BB] Incidentally, as part of other changes requested by implementers 
>> during the survey, we've changed the following:
>> s/will need to be defined/is preferable/
>>
> [GF] Unsure that I do like "preferable" - because I don't wish to 
> prejudge how TSVWG will handle new methods in future, and I would 
> probably will need to re-read to check this. Although perhaps, I could 
> now suggest:
>
> "As with all transport behaviours, each congestioncontrol will require 
> a detailed specification (which could be published asan experimental 
> RFC), following the guidelines for specifying new congestioncontrol 
> algorithms in [RFC5033]."
>

[BB2] I understood that we had been asked to remove any indications that 
specification of secret sauce (congestion controls) is mandatory. I had 
altered the rest from "requirements" to "recommendations", but I had 
missed this one.



Bob


>>> and Annexe A appears to confirm this.
>>>
>>> ⁃This would be significantly improved by replacing references to 
>>> DCTCP as a protocol with references to the congestion control 
>>> method/algorithm used by DCTCP: RFC8257 is informational and 
>>> explicitly explained it is not EXP.To me this text in the ID 
>>> provides many contradictions about implying DCTCP as a transport for 
>>> the Internet. That’s something that really grates with me and I much 
>>> prefer the much later statement in the IDthat “a detailed 
>>> specification (probablyan experimental RFC) will need to be 
>>> defined”. If the claim were different, relating to methods based on 
>>> DCTCP, that might be more acceptable.
>>>
>>> Making this a reference DCTCP as a CC method would be good to 
>>> address my issue.
>>>
>>> =================================================================
>>>
>>
>> [BB] I certainly sympathize with GF's concerns about causing 
>> confusion on the status of DCTCP. I thought I'd done well on this, 
>> but I can see now the concerns that Gorry raises. I hope the above 
>> changes are acceptable.
>>
>> Proposed resolution: See instances above.
>>
>>
>>
>> Bob
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>
> We seem to be converging,
>
> Gorry
>

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