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

[Gorry Fairhurst <[e-mail]>]

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.

>
>> 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.
>> 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]."

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