From nobody Fri Nov 13 00:14:10 2020 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0083A14C3; Fri, 13 Nov 2020 00:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT-8yEf8uq1t; Fri, 13 Nov 2020 00:14:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47D53A14ED; Fri, 13 Nov 2020 00:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; 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 [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) 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-BeenThere: tcpprague@ietf.org 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 Sebastian > On Oct 30, 2020, at 19:42, Bob Briscoe = wrote: >=20 > Folks, >=20 > The co-authors of ECN L4S ID have been reviewing the correctness of = the normative 'Prague' requirements.=20 > See = https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3 > This is the first of 2 emails, about 2 of the requirements that we = think ought to be reworded a little. >=20 > 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. >=20 > 4.3. Prerequisite Congestion Response > ... > CURRENT: > 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=20 > Appendix A.1.5 > for rationale). >=20 >=20 > PROPOSED: > A scalable congestion control MUST eliminate RTT bias as much as = possible in the range between the minimum likely RTT and typical RTTs = expected=20 > in the intended deployment scenario (see Appendix A.1.5 for = rationale). >=20 > 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.=20 >=20 > Cheers >=20 >=20 > Bob >=20 > --=20 > ________________________________________________________________ > Bob Briscoe =20 > http://bobbriscoe.net/