Re: [tsvwg] What TCP to target in TCP-friendly [was:A word for "does not have a significantly negative impact on traffic using standard congestion control"?]

[Bob Briscoe <[e-mail]>]

Gorry,

In my original question on this thread, this wasn't about which TCP to 
compare against (when Sebastian said that, I didn't correct him). My 
original question was about how to describe the fall back behaviour in 
response to a loss. The draft currently says:

       ...a scalable congestion
       control MUST react to packet loss in a way that will coexist
       safely with a TCP Reno congestion control [RFC5681  <https://datatracker.ietf.org/doc/html/rfc5681>] (see
       Section 1.2  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#section-1.2>  on Terminology for definition of Reno-Friendly and
       Appendix A.1.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#appendix-A.1.3>  for rationale)



When I wrote that I had no intention of it meaning "Fall back to Reno." 
I had in mind that Cubic is considered Reno-Friendly, so I had figured 
that choice of words would not preclude falling back to something like 
Cubic.

However, a number of survey respondents were concerned that it might 
preclude their favourite congestion response, with less sensitivity to 
loss than Reno. Hence the quest for a clearer form of words.




Bob

On 16/03/2021 12:14, Gorry Fairhurst wrote:
> On 16/03/2021 09:39, Sebastian Moeller wrote:
>> Dear All,
>>
>> in the cited response Bob proposes to define TCP Reno as the 
>> reference TCP all TCP-friendly protocols need to be compatible with. 
>> I had a quick look at what TCP CCs are actually in use, and according 
>> to wikipdia, all major operatig systems, Windows10 (since 1709, 
>> 2017), MacOs (since Yosemite, 2014), Linux (since 2.6.19, 2006) 
>> converged on CUBIC as the default TCP congestion control algorithm.
>> Given that data, I propose to not enshrine YCP Reno's behavior as the 
>> current applicable reference, but instead TCP CUBIC.
>>     For the L4S drafts that does not change much, because the dualQ's 
>> unfairness towards non-L4S-CCs does not seem to care for the exact 
>> way a CC is NOT L4S,
> <snip>
>> Best Regards
>>     Sebastian
>
>
> This seems an editorial matter that we should simply get correct. The 
> IETF has a PS specification for Reno. RFC 8312 is informational, but 
> TCPM recently adopted draft-ietf-tcpm-rfc8312bis-00, targeting 
> Informational status.
>
> My own (personal) suggestion is that we use text that says a "CC 
> specified in a standard's track RFC" and give refs to both Reno and 
> Cubic as examples, although I'd be interested in others views also.
>
> Gorry
>

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