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

[Sebastian Moeller <[e-mail]>]

Bob, list


> On Mar 29, 2021, at 02:43, Bob Briscoe <[e-mail]> 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 tds track RFCs.

	[SM] This is exactly where my argument about the reference TCP becomes relevant. Unless you want to fully enumerate the ever growing set of protocols.CCs that willingly cooperate over the internet, you need are better of with defining a reference behaviour such a CC needs to cooperate/peacefully coexist with. And IMHO taking the dominant TCP's behaviour is a decent starting point, given that TCO is still a very important protocol over the internet. Since this is about coordinating behaviour IMHO the more detailed the description of the reference the better, if a reference implementation exists even better, then one can design against a spec and test against existing implementations.
	And to be clear, this is not an attempt at rephrasing your position, but an attempt to progress the discussion (like the last time around, where just doing it implicitly resulted in you misunderstanding what I was trying to do, sorry for causing that confusion).


Best Regards
	Sebastian


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