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 <ietf@bobbriscoe.net> Mon, 29 March 2021 00:43 UTC
Return-Path: <ietf@bobbriscoe.net>
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 E41023A2B21 for <tsvwg@ietfa.amsl.com>; Sun, 28 Mar 2021 17:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.432
X-Spam-Level:
X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 YsrsM3XMwyry for <tsvwg@ietfa.amsl.com>; Sun, 28 Mar 2021 17:43:39 -0700 (PDT)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 390943A2B1D for <tsvwg@ietf.org>; Sun, 28 Mar 2021 17:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CFqX1V3f+s3oT3ysjHzN7fnkZDOjlv2LwY911Bm5JyQ=; b=HrDxZerWfCm+uVweA59NbQxtF FZ3gNq3qK4Ypvx5HQT9rcBBPyDpA7DP2eGOy3RSWaVp79ybN8+rODlr9On5UhDXlpcWKcToG2qA3i 4LERUWaIapH/Aaa54POOe3AsdcJXYc8svEs1qeEAX1TZQL9O1fJOoTkAjBbaylui9bsD3PTBnxX3x 8KNqWIbb2n5oQI7AYE2PLYHubJTrN+brZnNYAgSf5T/p45rGHHe+G+7uryFjgy380RBPTgOGaIfBc Kxw0njpPvPwA76aMCmOM3z2p2SCj2b4YUL7V5Z3ttwsKMjIDcBdtGP1DaZAN/zU6E3BMXT4MaQwfJ Rx6qV8lAA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:47712 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from <ietf@bobbriscoe.net>) id 1lQg0H-0006A6-2K; Mon, 29 Mar 2021 01:43:37 +0100
To: Martin Duke <martin.h.duke@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Sebastian Moeller <moeller0@gmx.de>, tsvwg IETF list <tsvwg@ietf.org>
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>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <8e7cb9fe-e9fc-0b93-6f52-392b28a1ecca@bobbriscoe.net>
Date: Mon, 29 Mar 2021 01:43:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAM4esxTPH_nPrfSRYYAbu8k4CEUP=zQhwuxC7KZ+LVLeRc7V=w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------61EC370A7978176071964306"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_yJaLqwYjNhVBJEZ2ACTA3MoxQI>
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 00:43:44 -0000
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. 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 > <mailto: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