Re: [tsvwg] A word for "does not have a significantly negative impact on traffic using standard congestion control"?

Bob Briscoe <ietf@bobbriscoe.net> Tue, 09 March 2021 23:11 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 E69A83A10CA for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 15:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
X-Spam-Status: No, score=-1.433 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, 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 N6fLczodQYZw for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 15:11:21 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 A1A4F3A10C0 for <tsvwg@ietf.org>; Tue, 9 Mar 2021 15:11:21 -0800 (PST)
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=IFX2S6ACuBNsFHAsut9UnErzwlyKcE1QPby84Mj+tV4=; b=XTRJTqaky6H6Ydz6DOmWEQoNL iquNE4iumm01YfTUZC7/4cHU3+llgsChxmOOj1aAjdm/ZZxDXdyH+w+uPR6E6AOUO5v7t8Jt3ooAq tjpyAJq3ALKFqR/pkm4FIZKkNaQcXmuTGUp5Si0ibiJRgJlxnbKvuihHFtX9gOG4AxuY+fMz2SeXn +XkTwHieSZbxZQQzD8SWNOTWf3L+rSYxej2vKDL+8xdPuKJFf5v5Ninii7rz0EaYObKgFOZ4TfSpF XsgF+OBEXUh5XviE/dkP+82RVHxnHq+/FPuao0iS4q8U3YAxUyEywV7IIKt+rZwY+xMCXpsLrx+L1 n2UgasbNg==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:42252 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.93) (envelope-from <ietf@bobbriscoe.net>) id 1lJlVW-0007Jt-7V; Tue, 09 Mar 2021 23:11:18 +0000
To: Ian Swett <ianswett@google.com>, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
Cc: tsvwg IETF list <tsvwg@ietf.org>
References: <9d807812-78a7-6066-5c5f-6f2b02507439@bobbriscoe.net> <CADVnQykGJNo3wF7pr4_OYxtzQAaN_A3y6trOQO3T2B8bWiWG+w@mail.gmail.com> <CAKcm_gPLRt9L=uPMo9v-=fxDRpgLiRa-mcDb2zFoMDReLMz4jQ@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <d59fb5ce-7d72-5df7-5a58-b0e9ca0871ba@bobbriscoe.net>
Date: Tue, 9 Mar 2021 23:11:18 +0000
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: <CAKcm_gPLRt9L=uPMo9v-=fxDRpgLiRa-mcDb2zFoMDReLMz4jQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------7D7991323825B3E1F75C9E73"
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/NL6txokiNbSWuDu4SWI7ha2uu5M>
Subject: Re: [tsvwg] 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: Tue, 09 Mar 2021 23:11:24 -0000

Ian,

On 09/03/2021 02:54, Ian Swett wrote:
> Thanks for moving beyond 'TCP-Friendly'.
>
> My best suggestion is 'fLow-Impact'
>
> I'd also be hesitant to put Reno in the name, but I think a name like 
> Reno-compatible/considerate/accommodating is ok if the term is still 
> anchored on Reno in some way.
>
> The goal of this new term is to depart slightly from the traditional 
> definition of 'TCP-friendly', correct?  ie: If there's an 
> environment(ie: High-BDP with exogenous random loss) where Reno can 
> only utilize 1% of the bandwidth, and another congestion controller 
> can utilize the other 99% without significantly changing Reno's 
> bandwidth, that would not be 'TCP-Friendly', but would be '<new term>'?

I think the concept of using what Reno can't has been around for some time.
I was looking for something more than that.
Something that's not as sensitive to single losses as Reno. Which means 
it could push Reno down (somewhat more than say Cubic in Reno mode 
would), but not "significantly".


Bob

>
> Thanks, Ian
>
> On Mon, Mar 8, 2021 at 9:35 PM Neal Cardwell 
> <ncardwell=40google.com@dmarc.ietf.org 
> <mailto:40google.com@dmarc.ietf.org>> wrote:
>
>     On Mon, Mar 8, 2021, 8:19 PM Bob Briscoe <ietf@bobbriscoe.net
>     <mailto:ietf@bobbriscoe.net>> wrote:
>
>         tsvwg-ers,
>
>         In the survey of the L4S Prague Requirements, we got quite
>         significant push-back from developers about our two
>         requirements to fall back to Reno-Friendly (which the draft
>         defines as a translation of 'TCP-Friendly' into
>         transport-agnostic language, 'cos TCP isn't the only transport
>         these days).
>
>         Basically, people don't want to have to fall back to something
>         as lame a Reno (apologies if that's disparaging, but I'm just
>         the messenger).
>
>         I was hoping people would interpret 'Reno-Friendly' liberally.
>         But everyone takes Reno-Friendly to mean quite close to Reno
>         behaviour - not surprising really, given the definition of
>         TCP-Friendly in TFRC is roughly within 2x of Reno [RFC5348]
>         (pasted at the end).
>
>         What I'm looking for is a word that means "does not have a
>         significantly negative impact on traffic using standard
>         congestion control", which
>         RFC5033 allows for experimental congestion controls.
>
>
>
>     Reno-considerate?
>
>     Reno-accommodating?
>
>     neal
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/