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

Sebastian Moeller <> Fri, 13 November 2020 08:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A0083A14C3; Fri, 13 Nov 2020 00:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 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, 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 mT-8yEf8uq1t; Fri, 13 Nov 2020 00:14:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B47D53A14ED; Fri, 13 Nov 2020 00:14:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1605255199; bh=CIucrS9zJ3TjfuB+2T6E0+0YTwtThaN5iH9NFjj4Hqg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=bae0jKt/ICgtf2A1OhVxa43/rirgHEo4fg7syf0cDSZ8bqwBVeJgtcawT848ARL4Z R9IhPKzjbHIcV7j30egg3r111cJakKo9rpcSJhhgauNCiTQvJNlz4ZAIsQLnrfteja D0a8KdN/BcVhk10XBf27QQ+ANX9v4Gbs6WSf83NM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1McH9i-1k18iJ2PgC-00ci75; Fri, 13 Nov 2020 09:13:19 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Fri, 13 Nov 2020 09:13:17 +0100
Cc: tsvwg IETF list <>, iccrg IRTF list <>, TCP Prague List <>, "De Schepper, Koen (Koen)" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:SUyON4oqldymy1bE2uFJzSZvt9SaKBc3JR7sOgKUJ903gBe5ylI dJ1I4Ds/COZ52l0YQUCh8QqVOGLQdeTHJlhHbudDXHoa6w7pLh3eJK9l7eUE/+5B/njzcue 4jP12d3A2tpbmTkxGJpkVoS15AvqLOO8vGeKVbgPKSPtqv8cL3L6telPayZd93fSuLqBLaf gBNU9cg2OfFENAWykImZQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:bsuzGwrlYzo=:jOuX4AD7dIzw4GLI1+wbLa yDh14NfPAVDXgtsAKCNR1ObRuLsp+3i1SzlRUMHgy4jWDzgv8rLQ9Kww63uHbSe/LOKXVcPzw sZbAYaTTULxwAsdBKnonDWCf8iYSoJznjrpCnsWquQR+LFhlXFEs/TXpSASTBV7Kd36otcQRy h/m4nvS4Ln+BBgPEPXX0R7UxjffEeADnsDTlPa442Ot0XY69N4zd4+d6F77ZirRJTwQLKUMU1 H60kFG9VNbCB52wAjqlTHuT5+Q8PMs0oDuv2I2l+k3Y+puV9Abzv+TdOJ7vNb7SF0iJMn04Dp QLhqCP5ZKhO5QXET+V3/cKPWZcvM6rCKzXmD/7CNZcY+qZ/d2yUSOBeX38ornwr5GoEh+sKN0 x1Viu3wEsamHv927K/+1VvHCXHZ7A55M6dZ5eacDn8g0abrALzjyq5AryRtDWsEP429Af1KNe ByUkULoTOzxtYjIwy/IJ2yCBPf0Y6KBsng4zeLYlvkNlBs6pZXuS0n1F72j+3PNIjHnWrhnwC T8brSRbg1njVEIqY2jsZjsxNFpvSEPXxjcY1ly0x9cdg7RxXFCThbki84DydNvIMIRLqxWqkW kcLCV4DHp+WXGsOn9AfjC+I8pjwHyay3nI9RoP6aBIpVSfXXSVPX8tmRXs2HmfevKHFtt9V8r sLROaY94G+JbAeCR6MRlAoqOgwj8ldvWMTmti9IDWivgBaMFf+4jD12GrsYnPiv+sUIejPm4m wG6l0Za8ZszYOOaxhukAEeD+EOF/Wmp5q5MXUcaXqhxUqJygsQDGVogxA3RK7QHGWWJ+7IFtM e1MBPlJ9PsYpS7o3VIfRAcCWhFQ+d95Y8tltCjR/Zv95U1+ty3NFTjE2L/b/ptir8sbjAauj1 I+F/UetZziQ7uLTpNnqQ==
Archived-At: <>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text (request to reject)
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: Fri, 13 Nov 2020 08:14:09 -0000

Dear list,

given the recent data by Pete Heist and Jonathan Morton, it seems that the combination of TCP Prague and DualQ introduce a level of RTT bias not seen before in the internet, including noticeably stronger suppression of long-RTT Prague throughput by short RTT Prague. Under that perspective it is clear that L4S does not at all "reduce or eliminate RTT bias" but makes the situation considerably worse. Allowing that behavior to stand, by changing the requirement to Bob's proposal below is IMHO not acceptable, unless our goal in the WG is to built a fast priority lane for short-RTT flows at the expense of everything else, like long-RTT flows or god-forbid non TCP Prague flows.
	The proposed rationale " there is no need to mandate that an L4S implementer does no harm to themselves" is problematic, if L4S and L4S-compliant transport protocols are intended as replacement for traditional CCs, as we clearly would turn the internet into a mostly short range affair.
I have claimed in the past that RTT bias is an unavoidable consequence of differential "reaction times" for control loops at different delays, so I always was critical of the "reduce or eliminate RTT bias" mandate, but I believe firmly that a "do not make RTT (considerably) bias worse" than it is today should be a non-negotiable MUST requirement for any L4S-compliant transport.

Best Regards

> On Oct 30, 2020, at 19:42, Bob Briscoe <> wrote:
> 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.
> 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