Re: [tcpPrague] [aqm] L4S status update

Jonathan Morton <> Tue, 22 November 2016 20:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8492A129B72; Tue, 22 Nov 2016 12:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 3eBdAbwW3yhe; Tue, 22 Nov 2016 12:37:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ED0F129795; Tue, 22 Nov 2016 12:37:28 -0800 (PST)
Received: by with SMTP id n6so4243626qtd.0; Tue, 22 Nov 2016 12:37:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3SsoJplVkMmbgtJhxpx8FPieAh4oV/A4yIIM2kcOOYw=; b=tj1OVwjr6aCyPIlwJgCpfZykO2ZYnQpsiIt6yAtq5Y6Bd186XXIfAVNgxqY90+vWqY bv8mU5w2xXkYpm3dEd2t0h2iP9Q6r1z2/y+Y3YSb+6G4tC47tdz++Qx2Nv+uhEvKwSvD 7xAQWdUCQUnj5BKZLza0n6Gw4bklSnMhocxVdT55b+VaV27wKhBP++0Iq5XPFcztE2oZ 0RuXq3iAxGxpHUpI+VyCLLhjU6o6gnBrl4WBobRd5wHFS5dxAqu0kt6Xob2TcoSKXTWs BPkeHkDkrJDLFyrP8lcZ+YtHU1kgMWPwWV/T7Z+pm2xCFw8mIRtvi8wzBg7ztDOsDPJE fpYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3SsoJplVkMmbgtJhxpx8FPieAh4oV/A4yIIM2kcOOYw=; b=KcmK+NEDK1vb18CYBhcJe30jYJQcn+HG+0xH5Ue3BfZ7A6nHZBPupGE8V8FcDEmqqI SqIsgIaf2/noQqVVvNXHrVDfq9hx8htcppgwfMLNTD2Hgm6hEKZNJP9STvPH9q9RCC+4 ZwUssGxSHbxyFXI138GhbH2TMvZBxiGm9Is+BkFZXA4UiEHme7+FoHa22hJ32/Bjs7EA wRIDFAVppS8d3RG5nTDne5mz8EFYmyt/5UIkI1d0grTHVFhv4MbnvjfXsVVgSOx2SrDz GuEHvbL5ibYtfmD1KpiR4vxo9n1fiaeliG55EwSYQz3O+qO5tiwQl3O2mnxg9xMHUZ4R Vx9A==
X-Gm-Message-State: AKaTC01BxFTDj0BdAQu9pBU0p8cjPgOXhHfcjBmZ7c8y37/77jf3iOPHwwgXH12yi7siBg==
X-Received: by with SMTP id g19mr4977942lfg.162.1479847047464; Tue, 22 Nov 2016 12:37:27 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e78sm6616283lfg.23.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Nov 2016 12:37:26 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Tue, 22 Nov 2016 22:37:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: TCP Prague List <>, tcpm IETF list <>, "Bless, Roland (TM)" <>, AQM IETF list <>, tsvwg IETF list <>
Subject: Re: [tcpPrague] [aqm] L4S status update
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Nov 2016 20:37:35 -0000

> On 22 Nov, 2016, at 21:09, Bob Briscoe <> wrote:
> {Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time.

If you have intervals between events which follow a 1/sqrt(N) sequence, where N is the number of preceding events, you get an event frequency which increases linearly with time.  This applies directly to Codel’s signalling strategy, which is to start at one mark per (assumed) RTT, and to increase the marking frequency if that was insufficient to control the queue.

When you have multiple Reno flows sharing a single queue, there is a sqrt(N) factor in several of the characteristics, where N is the number of flows.  When such a shared link becomes saturated, all of the flows must be signalled to slow down, but for stochastic reasons it’ll probably take more than N signalling events to do so.  Increasing the signalling frequency while the queue remains insufficiently controlled has a good chance of quickly finding all the flows, while dropping relatively few packets (of non-ECN flows).

I’m reasonably convinced that Codel is a near-optimal solution to congestion signalling on TCP-friendly flows.  Regrettably, the latter are not the only type of traffic actually found on the Internet.

Really, the central assumption of Codel is that each flow requires only one congestion signal event per RTT to cause it to back off.  Codel stops working well on traffic which doesn’t obey that assumption (a linear increase in drop frequency is inadequate to mitigate a flood - you need to work with drop probabilities for that), but it *does* work acceptably well with multiple flows sharing a queue, due to this operating-point search.

 - Jonathan Morton