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

Sebastian Moeller <> Sat, 31 October 2020 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2EA33A0D01; Sat, 31 Oct 2020 08:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.548
X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZzQHMjLLImTj; Sat, 31 Oct 2020 08:50:31 -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 885193A0CF8; Sat, 31 Oct 2020 08:50:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1604159383; bh=oEcl0gNmiuZHCH/gW4SyPaIB1nu+J2Qw3IBqxlFHJIA=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=YRK8F3qVddsoHX2B0Iw/Ivxwby0intyAXW0sxVdivSA0/IynVi7tPG5hyeRL6CgaM nz9QUCG6M6ETTYJ+cSlLUMlG0B40mBm6iiAX+l2OXdr9VbFfH4XEqQMPHPSFjbrcZa MY3Oi/Nww34IWsfOVPQKXX9zqF30BCfBrBOQjJp8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (3c-app-gmx-bs36.server.lan []) (via HTTP); Sat, 31 Oct 2020 16:49:43 +0100
MIME-Version: 1.0
Message-ID: <trinity-fd329c3f-42fa-4cf6-b038-d5b3c4101f42-1604159383392@3c-app-gmx-bs36>
From: Sebastian Moeller <>
To: Bob Briscoe <>
Cc: tsvwg IETF list <>, iccrg IRTF list <>, TCP Prague List <>, "De Schepper, Koen (Koen)" <>
Content-Type: text/html; charset="UTF-8"
Date: Sat, 31 Oct 2020 16:49:43 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <>
References: <>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:vFyqoXSTx7Pr2ufpn6guSVyvPI6Ajf8/V0a1YHjDoIHq5sRSEc7idaYR/sLMA54tHQNpJ PFE9hBaJzQiIvMj5wJ9zVc365SFioe8g5j33FABnFGd1t4AbZAz1O/ZF3zED4lDI1mj2fiH39gA4 4oLp041W2+BzDygEh+l+YYzir2F0jAxgvUVYtXi9QTgvTXWeajmMsKmwiADi3kirZw0dnSYN4CJ8 uWjBI093ofLYdJla1cWZKGaGygVQKidqPqvQWHMLHHX8yVlQYRPz4Bx7mMfeMakrN1lLcwT9vfsz yQ=
X-UI-Out-Filterresults: notjunk:1;V03:K0:9ezIyntOlqU=:Nzie/gOS1kgerBtsGnr/qE NmczJD1wPmixszjfNPv5zrIZlZyqQzh5+ra0CipQGmAaxthhnke8JfODqv3C7Wru1SzRRCsVn fv14mlF98o+q6zoLyo8T49C0H8xMgHaAbncedHldzWwlRR9bWPfFIfkZWvaNiOICtAd1EDCUZ laFK1J6hqoRkhCHnVidvbeZh1IJk7pprBAqHwMJaVPEUFAZqh+12VUN7rvY8Evl+WeaMFlzoP i6jAQc429JuxRTTiH8uJ4TNDFH902zra9qrgFWhbLBNo+QjjYvCciI+sLLo4hvJdb4U9qj9MS qkpdvO0RVR+ugcELPhSkAIw9edX7+NMBHZq/EkKm7T1CzJm4S8AtWAbtg7gecBmrPa/fbhsvj VH9WtqFNQ4S5I0h2/OucHDRGWRLPohFoyKcHq8yHyI1LNz9H/h8DMNVq5ZlZW98r6dEePaegP uQ8vp5QavgnhaLY94Nrb1tTRgnYTr0TikR/E8C+urQ7n+Dl9RGfbb8rj469d9+H176QesYL6i 4UX7sbEC3MXjbmh+TBJhkNDx/EvWj+xP/R+cmMtM7zXIg05dcwJpkotRa6EominbRK/j61jCA Q0THzs5mWbVcY=
Content-Transfer-Encoding: quoted-printable
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 15:50:34 -0000

Dear list,
please note that both of these "requirements" hedge against the fact that RTT independence is almost impossible to achieve from the endpoints (as it is a consequence of buffering at the bottleneck), originally bzy stating "as wide a range of RTTs as possible" (which given the phisical constraints in reality is equal to the empty set). Replacing that non-requirement with a differently worded version ("as much as possible") does not change anything substantially, except for making TCP Prague appear less of a failure. 
IMNHO this requirement for an L4S compatible transport, should be replaced with a requirement for an L4S compliant AQM (as it is limited queueing at the bottleneck that causes most the issue) MUST at least perform as well as a dumb FIFO, a mark which DualQ at short RTTs misses badly. But I guess, a no regressions against the status quo requirement, will probably not apply to L4S.
Best Regards
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

The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.
    See" target="_blank" rel="nofollow">
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.
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" target="_blank" rel="nofollow">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.


Bob Briscoe                     " target="_blank" rel="nofollow">