Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?

"Holland, Jake" <> Tue, 12 November 2019 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 193041200A4 for <>; Mon, 11 Nov 2019 23:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jFzyysSKhRpj for <>; Mon, 11 Nov 2019 23:19:36 -0800 (PST)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B57D41200A1 for <>; Mon, 11 Nov 2019 23:19:36 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id xAC7HOU3015238; Tue, 12 Nov 2019 07:19:32 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=roXocq/uWNdmAjzz90rQkeQings93pEEqfC8tyiZfGI=; b=KeRPkYKYm+CJVqdIeCQvVsYzd5u5VOYGQ27pgsJx2+QHd6+S3RkBCRYTIf2boWbmvEQB rq9Q95qWW6ZdjvvlzTaK9NacEZzb+G4RfMsFkzza8fxVS/HfSinB4Akx/iENybntSuWo +FcPezgpJN1n5HqN/UZ63gHD933V/VU5X1gD4Eex/RbmPFwNftoFQZaZD5D2stebwjgv 4ghX5deuA96wSpPCC8GP+qINTgk9wMMx0IB5u53EcIN98iAdZJEKbsWHYNRwucou0Y2o 5X6aIMzEHpjrPJeINPNmNzdZR4PmfXRp7NWEG8afiFkY9YI1ZpelWDlHGbip/Pyb/4i8 eg==
Received: from prod-mail-ppoint4 ( [] (may be forged)) by with ESMTP id 2w5p6p5y9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Nov 2019 07:19:31 +0000
Received: from pps.filterd ( []) by ( with SMTP id xAC7HQZp017520; Tue, 12 Nov 2019 02:19:30 -0500
Received: from ([]) by with ESMTP id 2w5sp3w3j5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Nov 2019 02:19:30 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 01:19:29 -0600
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Tue, 12 Nov 2019 01:19:29 -0600
From: "Holland, Jake" <>
To: Wesley Eddy <>, "" <>, "Black, David" <>
CC: "" <>
Thread-Topic: [tsvwg] TCP Prague's RFC 5033 guidelines status?
Date: Tue, 12 Nov 2019 07:19:28 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-12_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120066
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-12_01:2019-11-11,2019-11-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 impostorscore=0 mlxscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911120066
Archived-At: <>
Subject: Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2019 07:19:39 -0000

Thanks Wes, this is a helpful start.

I think the [DualQ-Test] reference from dualq also probably fits
in #2: difficult environments, with an examination of behavior in
the presence of fixed completely unresponsive UDP traffic at
various levels:

What my request was about is that I suspect there's probably more,
it's just hard to comb through it all to see what's missing.


On 2019-11-11, 20:49, "Wesley Eddy" <> wrote:

Thanks, you make good points.

I noticed that it was done very clearly for CUBIC in which looks like a great recent 
example of how the 5033 topics were each addressed.

For Prague + L4S, I think we have a lot of material spread out in 
various places, and are pretty much covering all the bases to some 
extent, but lack a single place where it's all collected.

Here are my thoughts on what we have:

(1) Impact on Standard TCP

Parts of Appendix A and Section 4 of l4s-id draft are relevant, e.g. 
A.1.4 "Fall back to Reno-friendly congestion control on classic ECN 

Results w/ CUBIC + Prague in github/heistp/sce-l4s-bakeoff and data are relevant.

Issue 16 results from are relevant.

4.1.1 of the dualq doc is relevant.

(2) Difficult Environments

I'm not sure this is super-deeply investigated yet?

Some parts of the dualq draft touch on it, though since dualq is a 
construction where the actual AQM algorithm(s) can vary, it's maybe 
sufficient that those AQMs are suitable for the environments they're 
used in?

Scenario 5 in github/heistp/sce-l4s-bakeoff and tests 
may be one data point, though I think the gist of 5033 is wider on 
wireless access, etc.

(3) Investigating a Range of Environments

Section 4 and A.1.6 ("Scaling down to fractional congestion windows") of 
the l4s-id doc partly speak to this.  A.2.2 ("Faster than Additive 
Increase") is also partly relevant.

The scenarios used for github/heistp/sce-l4s-bakeoff and data have some datapoints and use different base 
delays, but I think the gist of this in 5033 is probably towards wider 
sweeping of the underlying network rates, numbers of flows, and other 

(4) Protection Against Congestion Collapse

A.1.3 ("Fall back to Reno-friendly congestion control on packet loss") 
pretty much covers this?

(5) Fairness within the Alternate Congestion Control Algorithm

Section 4 and A.1.5 ("Reduce RTT dependence") of l4s-id are relevant.  
Also A.2.3 ("Faster Convergence at Flow Start") is relevant.

The two-flow cases in github/heistp/sce-l4s-bakeoff and data are a simple case of this (2 flow cases / 

(6) Performance with Misbehaving Nodes and Outside Attackers

Section 8 of l4s-arch + Section 4 of dualq and covers this?

Scenario 4 results from the github/heistp/sce-l4s-bakeoff and tests have some relation to this also?

(7) Responses to Sudden or Transient Events

This could be related to parameter tuning of AQMs used in the dualq 
construction and to Prague, but I'm not sure it's applicable to the 
higher-level L4S architecture itself.

(8) Incremental Deployment

Section 6.3 of l4s-arch covers this?