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 <moeller0@gmx.de> Mon, 29 March 2021 07:34 UTC
Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19BD3A33AC for <tsvwg@ietfa.amsl.com>; Mon, 29 Mar 2021 00:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeWQdBGlQEwu for <tsvwg@ietfa.amsl.com>; Mon, 29 Mar 2021 00:34:51 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0173A33AA for <tsvwg@ietf.org>; Mon, 29 Mar 2021 00:34:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617003242; bh=02OwwNDFcAdG87mR5XgxiQVH//zKfYBH+Sncnxbygis=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=JwaCRGDD13Qa+FTTHV2V+0ZlicvhYd3xQD+49CATtoPETL2lyZKr/wMgBgnTKDkY5 J5YHQFnQ4IHLs9DEuzYkriyVulNd/3CApBV60hbVnuw3N3Nh+6225dZGYbqVKhvGJS 7A7dsLDV9Zc6IsRXbF5TQrf0xvRaJBUA3PaVJpOg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MoO24-1lxhRa0JYm-00ooRE; Mon, 29 Mar 2021 09:34:02 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <8e7cb9fe-e9fc-0b93-6f52-392b28a1ecca@bobbriscoe.net>
Date: Mon, 29 Mar 2021 09:33:59 +0200
Cc: Martin Duke <martin.h.duke@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE80EBA3-9B25-4FF1-8B00-6BB110F36D55@gmx.de>
References: <9d807812-78a7-6066-5c5f-6f2b02507439@bobbriscoe.net> <457E3F32-CE3D-4B15-A067-C476DC1F5434@gmx.de> <eb9a54c8-3883-0bb2-d213-fdbe2707cafc@bobbriscoe.net> <136274F6-5B94-49EC-8338-9A6D81E400D2@gmx.de> <79c1c388-f35e-d6f9-9a9d-6ad28230a85a@erg.abdn.ac.uk> <CAM4esxTPH_nPrfSRYYAbu8k4CEUP=zQhwuxC7KZ+LVLeRc7V=w@mail.gmail.com> <8e7cb9fe-e9fc-0b93-6f52-392b28a1ecca@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:oFfHW0owjn93cm5ASZCIVW7mFfBJ0Mppcv6g926E97WB/UQzYai 2rxBCOsMkyBLWpSro3jrVq7G80I1A7mEqLwEmDz2Dvac17/N5l7Zi3P2KTI4PlDRfY1dUhW HnQh2tyig3fFWZ7yq8YoAbYAtw+cY0lexHOCVg0WMxKKUkzlOHCl0MGDqXE5xcQZn2bph5O +5uET9iA83lhfbA8nWLeg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:PtH2f4P6wt4=:WpPd6CXen29t72h9g518iV 9YoVUYn5qjpvBN/7ppmVs8Ng8dKY6CKb51fmTQN82BCha1glpFg1TNStZj7M42dAiGgxzYjgb 6XapxN4PLSJJJPu3/3Mjk24pzE75zCV86KeVXCh70EBcNRNqaaZntqOh2O66QKqzwOM5WXYpD T9mPHaFLD4HuJWNzr0zu9dGGsWTvDBN9Oi+lnshQlOqwd4TkzNVbi6+bhXX/j/NjwaBLbHtJy KMrYxH8ya/evwvu76YxrW3FE6jFHoInFBbvjgWvr6BQGKcTjxumbt/RTs4hTyeXlgfmYylUOD 6cJm3hjs0NeodlrwR1VP5HDlSqDZhOuBqu+9A55C5zqw5JnuEBqEHthrn4VFcOiLhieQ9HqgN HNhnAcNx9/ATh1LlezRtOLyBAGQ85YW+oPEMuGeCKXMcC6hlvMndgN+5ssbPc4jjAPAiLDBzw JrEBGyAVgFEpw2SRFKUk5dm7NpYboawBW3yWwDd7armxTrWOLRWyfOn/c3cjR+4zXrKf3ip1P o8XoAW+mRXdHGMZ5xjvByEvfUqOGEBey+EALvHCUVFBk0M8Bsl6nZQ0JLcNG9P5m29wbOlY4h kwkUP1KIl2+l8KvGuOHr6BGBkpsojhgsvu1NtVkHmzjX/GV2sHJnmU8tq4tINc323fBe3R9op l702az81BGxv4s4tMQF7jvh3k8w0kRzrZMKY4U1nEVioIUcs1dSXR1/VaD6WAAj9n61a5n272 8iqLF6aiW10hW64VBHf9XmuBLOFRQk3YlzRvu5AVL+He7btlmrKnKl4LkXRzKxrgspO3l8ODx eRXryNc0QWfYjJW+cSu9kRTnUljpEpEIMeBV/v1pnga8VVjLQXfiVBiq26Vsw50SW9Xejvw2D /ZEIZhGYNoZ1QdN5ffNA9/bj6qs8d2tSnglaRpIPjjxkHY6ouJvrlsbyXTX1KVuOz/ijfe0zC hrt5pvqygZHUDyYbb2F/HwmnIDkS4IugLrgDcJbBlZ+ej9DztI7REuDcv5Sfiz7FlsrbXxJ7O Gd8bwYWRga3P7xtUB8uTb13IlcL2jM0WpZl0xC3t+mT/N4eUgqEzdkSsWz6c+bIKtVdXtLerd i7r+7Y0bpMek4w2cvQ1ML+4BGq+cOsPuyImOPi9VxZkpFSyb12Hcj9B2a/UkVxM/sWISY4U7F R8KUI+NINH/FBBm6Ks9DmZ51ZTotsuwFvR0F1oA49WxoPInzNEUPMRnpNVC0vw9M+Mup0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7DO9mnuI8pdkn2u8kZB9x8CTsfg>
Subject: 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"?]
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 07:34:56 -0000
Bob, list > On Mar 29, 2021, at 02:43, Bob Briscoe <ietf@bobbriscoe.net> 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 <gorry@erg.abdn.ac.uk> 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/
- [tsvwg] A word for "does not have a significantly… Bob Briscoe
- Re: [tsvwg] A word for "does not have a significa… Neal Cardwell
- Re: [tsvwg] A word for "does not have a significa… Ian Swett
- Re: [tsvwg] A word for "does not have a significa… Jonathan Morton
- Re: [tsvwg] A word for "does not have a significa… Bob Briscoe
- Re: [tsvwg] A word for "does not have a significa… Bob Briscoe
- Re: [tsvwg] A word for "does not have a significa… Ian Swett
- Re: [tsvwg] A word for "does not have a significa… Sebastian Moeller
- Re: [tsvwg] A word for "does not have a significa… Bob Briscoe
- Re: [tsvwg] A word for "does not have a significa… Sebastian Moeller
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Sebastian Moeller
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Gorry Fairhurst
- Re: [tsvwg] A word for "does not have a significa… Lloyd W
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Bob Briscoe
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Martin Duke
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Bob Briscoe
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Sebastian Moeller
- Re: [tsvwg] What TCP to target in TCP-friendly [w… Gorry Fairhurst
- Re: [tsvwg] A word for "does not have a significa… Bob Briscoe