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

[Gorry Fairhurst <[e-mail]>]

Bob,

Please do propose text - I'd suggest not to solve the problems for the 
non-standards-track CC's: This could be a job for each CC to solve.

Gorry

On 29/03/2021 01:43, Bob Briscoe wrote:
> Martin, Gorry,
>
> The set of CCs that do not have significantly negative impact on 
> traffic using standard CC is much broader than the two CCs on the 
> standards track.
>
> For instance, this is needed to describe what an L4S CC is allowed to 
> fall-back to in response to loss. We wouldn't want to constrain 
> implementers to just the 2 behaviours that happen to have been written 
> up as stds track RFCs.
>
>
> Bob
>
> On 26/03/2021 16:44, Martin Duke wrote:
>> Gorry,
>>
>> 8312bis is Standards Track.
>>
>> On Tue, Mar 16, 2021 at 5:15 AM Gorry Fairhurst <[e-mail] 
>> <mailto:[e-mail]>> 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 Briscoehttp://bobbriscoe.net/