Re: [tcpm] "David's proposal" for cc class terms (was RE: [tsvwg] L4S status tracking)
Bob Briscoe <ietf@bobbriscoe.net> Wed, 13 November 2019 23:58 UTC
Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@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/tcpm/dt02flC-DhYtXo9ZbPrHWPxhnHc>
Subject: Re: [tcpm] "David's proposal" for cc class terms (was RE: [tsvwg] L4S status tracking)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-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/
- [tcpm] "David's proposal" for cc class terms (was… Black, David
- Re: [tcpm] [tsvwg] "David's proposal" for cc clas… Jonathan Morton
- Re: [tcpm] "David's proposal" for cc class terms … Wesley Eddy
- Re: [tcpm] "David's proposal" for cc class terms … Rodney W. Grimes
- Re: [tcpm] [tsvwg] "David's proposal" for cc clas… Jonathan Morton
- Re: [tcpm] [tsvwg] "David's proposal" for cc clas… Scharf, Michael
- Re: [tcpm] "David's proposal" for cc class terms … Bob Briscoe
- Re: [tcpm] "David's proposal" for cc class terms … Bob Briscoe