IETF Logo Mail Archive

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/

v2.23.0 | Report a Bug | By Email