Re: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S status tracking)

Bob Briscoe <ietf@bobbriscoe.net> Wed, 13 November 2019 23:58 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 3BCD3120837; Wed, 13 Nov 2019 15:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 yYOO0osTSn9K; Wed, 13 Nov 2019 15:58:22 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6BA8A120018; Wed, 13 Nov 2019 15:58: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:References:Cc:To:Subject:From: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=5BwCHQA4ZPGBFrS7Ykf53Lyw7gnkfCTWJaEd+FNSd8w=; b=18N8/RLfbRm5fKn0aku/oZXHA rBjsLTp6a9AdDMUC9cGJJNQ4k83tGX9iCtNPu0I6rZkOk/IjpJjGUKDG55VZt2Jdh9mWFEzYvkqM+ p3rAkkHGWanYw8rfTZcEMXN8qL4NIj0W58eONmPw3Vig34ZtJD6l8J8Reke9L40VNpFoigRIky4rH eMeguWkEehhg/OiDhLplPpHtaI9Z4IPlSlC3XLXfv1NJgEGlcI4rI3Ja9UM49YSDpJ2xDKg9WYmvy i0cb2pJEmCEcYy/51m9sfFE6QNIgVJNKoNjKJundzVSjpzZywYbrHd7PAU7U4ghahURz1KtX9Lhho 8IdqHBILw==;
Received: from [31.185.128.31] (port=52690 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1iV2Wh-0006HK-6L; Wed, 13 Nov 2019 23:58:19 +0000
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Wesley Eddy <wes@mti-systems.com>, "Black, David" <David.Black@dell.com>, "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <MN2PR19MB4045EAFC55061858895E2F0983760@MN2PR19MB4045.namprd19.prod.outlook.com> <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Message-ID: <f00c07c2-60ea-4ab0-1c1e-76e6d7b57e5d@bobbriscoe.net>
Date: Wed, 13 Nov 2019 23:58:18 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com>
Content-Type: multipart/alternative; boundary="------------971C34EEBF9FDA7615296D65"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CR_-T9lI7Kj5996fNQKowc09RyA>
Subject: Re: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S status tracking)
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: Wed, 13 Nov 2019 23:58:24 -0000

David, Wes, [sry, I omitted to include the 'Bob adds:' para below]

On 13/11/2019 17:43, Wesley Eddy wrote:
> On 11/13/2019 11:15 AM, Black, David wrote:
>>
>> In more detail than I explained earlier: in this forum
>>
>> We are dealing with two classes of congestion controls.  For lack of 
>> better terms the following class names are based on what the 
>> transport protocol throughput is proportional to where ‘p’ is the 
>> loss and/or congestion marking probability:
>>
>> - 1/sqrt(p)-class congestion controls: Includes most existing TCP 
>> congestion control algorithms, e.g., NewReno, CUBIC.
>>
1/sqrt(p) only describes the worst case that the coupled dualq AQM is 
designed to allow for. It includes cubic in it's reno-friendly regime, 
as well as beyond that. It includes compound and a whole host of 
slightly more aggressive congestion control variants than Reno, as well 
as ABE variants of each. It includes the proprietary congestion 
controllers used in Skype, Hangouts, Facetime, Zoom, Whereby, etc. It 
includes rmcat congestion controllers.

So I wouldn't want to use a name that implied everything in this class 
obeyed (or had to obey) a 1/sqrt law.

[Bob adds:] Here's a link to plots of the congestion response functions 
for a selection of congestion controllers that I prepared years ago. 
They are all what has been defined as Classic, except DCTCP and Scalable 
TCP (which is not just a scalable TCP, but the protocol that calls 
itself Scalable TCP):
     http://bobbriscoe.net/projects/latency/responseFns.pdf
Recovery time is the average time the congestion control takes to induce 
one loss after its responded to a previous one. You can see it's 
invariant for the scalable controllers.


Bob


>> - 1/p-class congestion controls: Includes DCTCP congestion control.
>>
>> Keep in mind that p is a probability that is usually << 1 when 
>> expressed as a decimal, e.g., p=0.01 represents a 1% loss/marking rate.
>>
> "Scalable" is the term we've been using in the L4S documents for 1/p, 
> defined in l4s-arch as:
>
>    Scalable Congestion Control:  A congestion control where the packet
>       flow rate per round trip (the window) is inversely proportional to
>       the level (probability) of congestion signals.  Then, as flow rate
>       scales, the number of congestion signals per round trip remains
>       invariant, maintaining the same degree of control.  For instance,
>       DCTCP averages 2 congestion signals per round-trip whatever the
>       flow rate.
>
>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/