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

[Gorry Fairhurst <[e-mail]>]

Bob, please see below:

On 14/05/2021 10:17, Bob Briscoe wrote:
> 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)?
>
[GF] I like to avoid doubt, so I agree. Anyway the text says RFC8257, 
then "it" - so I'll withdraw my comment. Your proposal looks good to me.
>>
>>>
>>>> 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.
>
>
[GF] I still think "specification required" is fine - This can be 
suggested as an EXP RFC, or it could be something else, but from the 
IETF WG viewpoint it seems to me that a specification is needed.

>
> Bob
>
Gorry
>
>>>> 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 Briscoehttp://bobbriscoe.net/