Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text

Bob Briscoe <> Sat, 31 October 2020 10:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6E6F3A1916; Sat, 31 Oct 2020 03:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MCJsozAb7iFR; Sat, 31 Oct 2020 03:38:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9960F3A1912; Sat, 31 Oct 2020 03:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=/ULJhj7w01hYscSHiYlLY2tIRpkPoDyGR4WXyUcl+9M=; b=WOKccYIS3mwWQ5TdTI/fiSvQoF Cf0bWokctz1nvyzzfTfpx8x4ag8nkZHxjhIpkVZ6T/cKFxYtXR5597aa1GAr5Nd7aFpAkB4dI++19 BlBEcaPFtl7ulHetzPqj8fU+SrCH6i78RIWFULymcZgUbMHnzri9uAM6TKaQ+RO4gZKrs6p8ecAGM sFJ0i4Xmyux23xz2V1lcaHqEQKP2gAlDnPhS/X9yleczlZMOJtWs659KL1tJyFG2YSxnLYT7DNZhM P7axMLxQ48dZvM5obrKRwgMaUQBpaLpbpSblAiBmEV5ekrKLHNBRppaUKwj7zT6KdJcasRIZr0nB6 DaIrULCg==;
Received: from ([]:60966 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1kYoH7-00FwiK-TQ; Sat, 31 Oct 2020 10:38:21 +0000
To: Sebastian Moeller <>
Cc: tsvwg IETF list <>, iccrg IRTF list <>, TCP Prague List <>, "De Schepper, Koen (Koen)" <>
References: <> <trinity-da9fe99f-0f0e-404b-bbce-0468ed38ff45-1604088791553@3c-app-gmx-bap50>
From: Bob Briscoe <>
Message-ID: <>
Date: Sat, 31 Oct 2020 10:38:21 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <trinity-da9fe99f-0f0e-404b-bbce-0468ed38ff45-1604088791553@3c-app-gmx-bap50>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text
X-Mailman-Version: 2.1.29
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: Sat, 31 Oct 2020 10:38:26 -0000


I am not going to respond to emails like yours that presume evil intent.
Please readjust your sad view of humanity, then re-read. If you then 
have nothing to add, pls stay silent.

The rate being inversely proportional to RTT is a feature of all 
window-fair congestion controls, including the Reno standard [RFC5168].
As explained in the rationale linked from the requirement, the only 
reason Reno (or any windw-based CC) doesn't continue to get faster at 
low /base/ RTTs is the additional queuing delay it induces.
So the more one removes this queuing delay (CoDel and PIE also suffered 
from this problem), the more the denominator tends to the base RTT.
So at the low end of the base RTT range, the inverse proportionality 
pushes the rate considerably higher.

A CC that has no RTT bias would satisfy this requirement.
But making that the requirement would have been overly prescriptive.
So we're trying to write the wording not to exclude the RTT bias that 
the Internet already works with today.
Particularly because the stability implications of moving away from the 
current Internet norm need to be treated with care.


On 30/10/2020 20:13, Sebastian Moeller wrote:
> Dear Bob, Koen.
> more below in-line, prefixed [SM].
> Gesendet: Freitag, 30. Oktober 2020 um 19:42 Uhr
> Von: "Bob Briscoe" <>
> An: "tsvwg IETF list" <>
> Cc: "iccrg IRTF list" <>, "TCP Prague List" <>, "De Schepper, Koen (Koen)" <>
> Betreff: [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text
> Folks,
> The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.
>      See
> This is the first of 2 emails, about 2 of the requirements that we think ought to be reworded a little.
> If you agree with the rationale, but think the new wording still doesn't capture the requirement well, pls suggest sthg better.
> If you disagree with the rationale, pls discuss.
>          [SM] This pretty much sounds like both an admission that the original requirement was so broad that is was never achievable, and, leaving a bad taste, an attempt to maker the gross hack of "slowing the CC response in TCP Prague" by the same 15ms that DualQ adds to the shallow queue to make DualQ less catastrophic at short RTT links.
> IMHO the requirement should be scraped, as there is zero evidence that it is at all possible to achieve (short of relaying on oracle schedulers, or the AQM knowing the RTT of each individual flow). AND the gross hack in TCP Prague should be taken out again, and instead of trying to cure the symptoms, the root cause of the issue, dualQ's misdesign, needs to be fixed for good. The observed inequitable sharing between the two queues is caused by dualQ and needs to be fixed by dual queue. As proposed this is like re-arranging the deck chairs on the titanic.
> More to the point though, once L4S is released into the wild, nobody is going to care much for the text in the requirements section at all, as compliant behaviour is not checked by L4S's AQM. So assuming that changing this text will have any other effect, than simply making TCP Prague compliant post-hoc (by tailoring the RFC requirements to the little RTT-independence that was achievable in TCP Prague).
>         In my line of work, something like this would be considered a bad faith effort close to cheating, but it seems that here at the IETF we operate under a considerably more relaxed set of standards?
> Regards
>          Sebastian
> 4.3.  Prerequisite Congestion Response
> ...
>     o  A scalable congestion control MUST reduce or eliminate RTT bias
>        over as wide a range of RTTs as possible, or at least over the
>        typical range of RTTs that will interact in the intended
>        deployment scenario (see Appendix A.1.5[] for rationale).
> A scalable congestion control MUST eliminate RTT bias as much as possible in the range between the minimum likely RTT and typical RTTs expected
> in the intended deployment scenario  (see Appendix A.1.5 for rationale).
> 1/ "eliminate as much as possible" is stronger than "reduce or eliminate".
> 2/ This requirement was motivated by 'do no harm to others' relative to existing standard (RFC5681 Reno) congestion control. So there is no need to mandate that an L4S implementer does no harm to themselves, which window-based congestion controls tend to do at higher RTT. Of course, this doesn't preclude implementers reducing or eliminating RTT bias for larger than typical RTTs, but it removes any requirement to do so.
> Cheers
> Bob

Bob Briscoe