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

Sebastian Moeller <moeller0@gmx.de> Fri, 30 October 2020 20:14 UTC

Return-Path: <moeller0@gmx.de>
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 8A5423A11F4; Fri, 30 Oct 2020 13:14:02 -0700 (PDT)
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 zce4MetnSfXE; Fri, 30 Oct 2020 13:14:00 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 1B93E3A11F3; Fri, 30 Oct 2020 13:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604088791; bh=w2G7VIZl3/tpH39ae/7OTfN8WnRQRzBS9hpYqILRflY=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=UFwOOa7a2iJMeKuDh8vvBm2T4r0EaKw5n/MCeNihDxI3UyaldcpluTwvW29svDvqD MfMCCEMbv449c8n+fvtcFLXwrxlTWaVX3UNm/EZ5s0NbjvednrtTHtLrqKcxwAoclY QY4svmDuXZXw9cTq0kHcbrMkhD1nlzR4aS5gmWZM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [134.76.241.253] ([134.76.241.253]) by web-mail.gmx.net (3c-app-gmx-bap50.server.lan [172.19.172.120]) (via HTTP); Fri, 30 Oct 2020 21:13:11 +0100
MIME-Version: 1.0
Message-ID: <trinity-da9fe99f-0f0e-404b-bbce-0468ed38ff45-1604088791553@3c-app-gmx-bap50>
From: Sebastian Moeller <moeller0@gmx.de>
To: Bob Briscoe <research@bobbriscoe.net>
Cc: tsvwg IETF list <tsvwg@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, TCP Prague List <tcpPrague@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
Content-Type: text/plain; charset=UTF-8
Date: Fri, 30 Oct 2020 21:13:11 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <c20cb7de-a6e3-ff18-e34c-cee8c0cfadf3@bobbriscoe.net>
References: <c20cb7de-a6e3-ff18-e34c-cee8c0cfadf3@bobbriscoe.net>
Content-Transfer-Encoding: quoted-printable
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:6UkuDv4y6rzDpzdtDOZLN8AD0NKPcnCoGKmaFWTZj+vguoy7C4uYnzUfRmzWF5n8P+5D+ fRDsY9zQieEiaYsFN4gpp19Od7cz4zAJ5A1OSYGIZOPyE1C1BmQ5yBuAXH0oqBQ+e5KDPG2BH9yD JAJ4MUTZc91veF0muSbceRGQ8+qudQFB6QkJiRpmWcBmDnOvlQ0fFbsXltIE1FNgVLLi7KjqSSiO lR9Pya/yY5o5cgYcnaNJYdNIevbdof7UGSx22HZ626rxDSm/JO023LND2I48ENPRMKpotaLkf0YB uM=
X-UI-Out-Filterresults: notjunk:1;V03:K0:VVFq+zCh9gQ=:e/fyVl553r5bOCkBjXzQP1 jT9ToPDZRaXaibIPdGHbjZbj8GcDoYMMXTFknsRD8olEEGrlrp0dwOG3LdphzjmfYzYPV4I5I mZMHZrFd6UcxEu8iIoTPcuQIY8201YviufI5Wxse7Wsnw/xC6byHkca8pMed+f40l1KSIEV8d 3/4Dh4KjSqig9qJJYJWInAEiprB950sU42QbCajXBLbBF9M+Ks4sZKm4tpKY0ZJNSz8JKES4S kAIi4hxUzZgOiQ6oqwLBvQ9qbu5dxHYEukPKhewGFU6zWkJrUrHq+P2ELMaxuWwntKaI35/Pi HQ0vTr6c5ZNyfLtDd74rgoaH2nRtpExdOOrTXCE6iKGz86kFNNrotqQ5MfoDg0FJxBHlOyq4c ZpGyl8+01n58Ht2jxcCaIz1vg4cLEbbbDrykli2DW0Cex30hxkkaj115eaXH+uixVRu3e6SOV gJOr0WsolO89opZ5UAia7tScaQQIbhf6yPao5M4eIRFeYpZXq9/kTDGO9vgwf/TVKzzhIQclx 8xBY2zSm1jcNrxUBbD6z6a5pm2UIUR3HDEmZHE+Q2M8Czbr9Jer/5DTl53xrtxJFCX2cjGfp0 /DscwUyrnkGn0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/PZs0aWJnDc9sV698FTQLycXaikQ>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text
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." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2020 20:14:03 -0000

Dear Bob, Koen.
 
more below in-line, prefixed [SM].

Gesendet: Freitag, 30. Oktober 2020 um 19:42 Uhr
Von: "Bob Briscoe" <research@bobbriscoe.net>
An: "tsvwg IETF list" <tsvwg@ietf.org>
Cc: "iccrg IRTF list" <iccrg@irtf.org>rg>, "TCP Prague List" <tcpPrague@ietf.org>rg>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
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 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.

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
...
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 Appendix A.1.5[https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.5] for rationale).
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
in the intended deployment scenario  (see Appendix A.1.5 for rationale).

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                               http://bobbriscoe.net/[http://bobbriscoe.net/]