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

Sebastian Moeller <moeller0@gmx.de> Sun, 01 November 2020 11:19 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 778D13A1070; Sun, 1 Nov 2020 03:19:10 -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 Hr8jEDaNvv5h; Sun, 1 Nov 2020 03:19:08 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 305253A1071; Sun, 1 Nov 2020 03:19:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604229499; bh=9MTt05YU5yjok8zjVaNPLYN54bPjdZVQ/Ne51rWaYY0=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=NlMCEcj2gexrk+evxtJ0uZjkwXQ8dH3JsVitVD0f7EzM28Et0lyic9LClfFAqr23y OROy8H5OGloZU0jkrnCrViqwf6QnuEwTkzTd7OcndcggsVmDcXE2QtrzPx4u2SLPiy yR2OHx19xmfPudaQKMMDjXokS203xkqtlofMIwB4=
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-bs25.server.lan [172.19.170.77]) (via HTTP); Sun, 1 Nov 2020 12:18:19 +0100
MIME-Version: 1.0
Message-ID: <trinity-33fabdc0-7921-4687-a8b7-57d3b477b4b2-1604229499398@3c-app-gmx-bs25>
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: Sun, 1 Nov 2020 12:18:19 +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:+7bFwXNx2+AlXPGpFLlL8PQ8BY7+FxmQHZg1VdGoiq2C3R9IPYK+eGjYN/IYYj4mdhfMd cX6sbY/A4XOKhkFWu/9cQeVj5O0ZRtzam0cSdgNGgV8UNjx6WsKAddeAqhjGHfbGsNjYwYEyQsWH FDOZzL+yErzX80U6g3ABsCqF2OqsLmzrL1RcytyHuRi68fVjfiHiqmO77xgf0oiQsJBtSLe1X1tj NRxF4MJ1s+ujCYzZU+NHwv8fQokClErBSqChEwiktD/D+JvAiogDlCcoM5d4bluKtGUiGa4MeF4t 8c=
X-UI-Out-Filterresults: notjunk:1;V03:K0:fr84n6WAIqE=:u6IzcQs+NASRwAb1pIKvDH 4rKfPo1zJeQM0RDvDiM8qTW/NpJ5zggHzGt84EUVP1c4U0WvH/6X7rSN9YouhYJ+YK85Hvd9T mVq8xgu9GPLpJDwD8KM5j8nxZ9kuRgP42kN1raKceBNvjQtlE/u1HHWbWJv/uAU/ON2vhrqDZ Zm1uTfSMDRAuRPxivCEn3eCF7Yzxr6BWdi+zz+6EnGuWDcq3YyXB+N0qUtozEEADuybJCOdgT CYfwmJGE18HAjnL48IL2u+0zvAdkxCozOgX1hy6BaCaC8IVKa01wmN5g/aNMm0wSCzbhlYjOB Op8+VcLMWmP+ZdRuzAEeuNEBTlSXRv4xoNKuf6mXsNgeg9zqVAmm/zCDG3HHvQWk9O/jRpYFv m31K+uhUwofN9Txsy5zvbVLNTxvW0z/HgXZF9W8ERggRL+H7wXH2bxRcJ8yBT8pEs3o+IO0pE BpAW4eEbXEbqzytJrR0Ug/geNQGxQlZJZsP8iZQFkQBTIoviNSWX9S/U/yMGtoybcm2OQf9vq XiNkL0XQPmGxDRrO+IwEni9KWdrQ5JpnGZZXRwbZWCUu79D7hIdF432ke0n5Ce3igKzETExk0 KD7Ow/mOsA0L8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/YKNXyDbwJAunbWfwyKUJX2d7UjY>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text [Proposal by SM]
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: Sun, 01 Nov 2020 11:19:11 -0000

Bob, Koen, Wes,

please find my proposal for a clarification below, 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.
 
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).
[...]

       [SM]
CLARIFIED: Any protocol aiming at L4S compliance will need to account for the fact that L4S dedicated reference AQM, the dual queue coupled AQM, inflates the RTT of flows in the deep-queue by 15ms (if the AQM is configured as described in the DualQ internet draft). This will effectively lead to short RTT flows in the shallow queue staving flows in the deep queue. Since DualQ#s coupling heuristic is not designed to undo this damage, it is incumbent on L4S-compliant transport protocols to undo this damage, by artificially slowing down their congestion response "simulating" an RTT of at least that 15ms introduced by DualQ.

RATIONALE: This a) clearly names the root cause of the issue and spells out the remedy in a way that protocol implementers do not need to guess what is implied by "eliminate RTT bias" and why this is not just an generally aspirational goal, but why the 15ms hack is required for L4S to actually be deployable, as the avoidance of congestion collapse for short RTT flows in the deep queue really depends on all L4S protocols implementing that hack faithfully.
       The proposed text also removes any residual mentioning of elimination of RTT bias on first principle, since not even the designated reference protocol TCP Prague actually achieves any meaningful generic RTT de-biasing that is actually applicable in good faith to arbitrary large RTTs. 


I add, that I still consider that hack unacceptable and am of the opinion, that L4S AQM's MUST to be required not to create this situation in the first place. BUT if the WG disagrees and is fine with rolling out a clearly sub-optimal AQM with a-priori known catastrophic failure modes, then at least my proposed text should be added, to unambiguously inform protocol designers and implementers of their responsibility.


Best Regards
         Sebastian



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. 

        [SM] You realise that this is pretty much included in the definition of reducing or eliminating RTT bias, to not do harm to flows of the same protocol at larger RTTs? That requirement, I am willing to bet, was not originally written to save Reno from L4S flows (if it has, it has been exceptionally badly phrased) but really to imply that the "new" way of things is going to be better in all relevant dimensions, more RTT-independent, less re-ordering sensitive, ... This whole rationale makes me somehow think "Oceania had always been at war with Eastasia."
        Then again, this whole wiggling around and post-hoc changing of draft text, basically just confirms my statement, that generic RTT-independence can not be achieved by transport protocols, not without significant involvement of the bottleneck queue's management entity. So again, I am okay with dropping the RTT-independence requirement, as "long as the fix DualQ's 15ms hack" is still added as requirement, unless preferably the AQM design and implementation is fixed and the issue is eliminated at its source.
BUT some chairs seem to indicate that the time for real changes is over and all that is still available are small changes in the text, and so I propose this change.


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/]