[tsvwg] L4S protocol requirements clarification question

Sebastian Moeller <moeller0@gmx.de> Wed, 18 November 2020 21:46 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05413A0E83 for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 13:46:12 -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 AFiJvutBrcAr for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 13:46:11 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 4CF043A0DA1 for <tsvwg@ietf.org>; Wed, 18 Nov 2020 13:46:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605735918; bh=bIzbw0wMS4Lk8/1pFd2oM8cwmoR7vnIBRimrtxvBh24=; h=X-UI-Sender-Class:From:Subject:Date:To; b=Kt9KECkX0dtjmBTNdNm2QPybeKieBoHWgZBLL8VGI4NARFCA3ROJguRPp6lIrusOH F4nn9oaWYlGm+I+17nZdKxnAKXt5djZIlnl25Vqkr/rodXGOYlOMaNk6QyZuq8KYan aoDuO543h48kpm/j51y7VUPqJM2+trA3VonzR97o=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([77.3.111.149]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGQj7-1kT9Jz2ROH-00Goc0; Wed, 18 Nov 2020 22:45:18 +0100
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Message-Id: <87ABE671-A129-4172-A617-7FD64F40D7E1@gmx.de>
Date: Wed, 18 Nov 2020 22:45:16 +0100
To: tsvwg IETF list <tsvwg@ietf.org>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:d05JyRuSwU5kHYVs+tcGlJf2lZpByDFG+fHI/MAHq9kt5k/zcFV 5lzmg/bWyqNk86EkozIIZEBm6SDY4JoSt8ET78xLp5wAJaW5t+6xLJYwSb+1Yidkvrxv+By jA1er2LHmSlcc0jKoRmqtzx5E+de71v7hGYKY2ew6GdtHfA3IQ9+ZXkICjfCzOVTV3xhNug WzMS2SZlftkQWTpn0fw+Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:32wmpabkT/c=:vyi53Q06cjRSy8Oo9zbNSz U1Gupr3Lng2ZiS5MYgqn4+XPOldtAONs1afvxA/gQngbTaXZyQ9HIRc3HqEwXfJdZpxdDP/hj jo5FzZA4gpoODwlWRFKRrhbr68JIQHpFg+H0V6A7jBcs47ZbKSibyVA1aSk4oSzNZfz5oYlVj lQ3tPu3DUjdOgP5FdTocXrMFQs0DG6LHdzqYs5ZzlkFLCvaBoQX9SAfFupIFHxiZEbC2xoWTr iZO4ssS2N2HW5km5teiBOhby93133KeyQheUzVGNjRfcIyuu5WWDZUugaArSlmGMf+olBjUMB Sm8jy5h89/E4dRJXn8hnKnW5r0iECmzLiGIMbC5aWy8XSgvtGeDBaZFnUmmR6f4kQtXLbqKMV jvkd0BIsbIHXJdAd6x0R+TZHV2b0v3gnyfyBRmvIk7L+y/URAOaQ99zP22er81+tpJE1IQFQC SqmPEUwDl7SNm8ac0FLj2zkT3QJl/AAJ/MmqjVUS5HS5lAuOGOOuOvpRmCQ1Lj6P3RRlLk6w5 jvg9uYEHcyMCiHOU/TKeMi7Hx40CuR32g4cXOWuegzwasRh6Hmvne6S+zJrrAHzOXO1yvDbo0 ODSmTjSL+hd2xKP+okIJc2LhjUnSU9txhf+dXyZgVhW79IQXckPGBVIYv400Frpc0Ays0jSwk J6KlDyWW7f8rR88BUFyTbE7ki6ADrrpdXQI9kTTR0rkk+eT9fPwMbVqrZyJ70M6VYVk20GiC4 2jQeNKLOnKRNFaf82LcUMoS4PGKZZfXZ+Qbf8qfUb9jgX9t6whCbh4HzZaG0SgtcCPX2NkuLL gyKrtZJkXlHUayiAzzSTX3hHKLIIeHBQZjUSaQZapJMH+h92QcZ8g7EqtjUv94pdVJeVXjf/5 9Udfpd/HIQD0aM/zycOw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3inGANiU0z9d2K84yPtl1sP_aN4>
Subject: [tsvwg] L4S protocol requirements clarification question
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 21:46:17 -0000

Dear Koen, Bob,

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-12#section-4 now states:

"o  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).

[...]
A.1.5  Reduce RTT dependence


   Description: A scalable congestion control needs to reduce or
   eliminate RTT bias at least over the low to typical range of RTTs
   that will interact in the intended deployment scenario (see the
   precise normative requirement wording in Section 4.3).

   Motivation: The throughput of Classic congestion controls is known to
   be inversely proportional to RTT, so one would expect flows over very
   low RTT paths to nearly starve flows over larger RTTs.  However,
   Classic congestion controls have never allowed a very low RTT path to
   exist because they induce a large queue.  For instance, consider two
   paths with base RTT 1ms and 100ms.  If a Classic congestion control
   induces a 100ms queue, it turns these RTTs into 101ms and 200ms
   leading to a throughput ratio of about 2:1.  Whereas if a scalable
   congestion control induces only a 1ms queue, the ratio is 2:101,
   leading to a throughput ratio of about 50:1.

   Therefore, with very small queues, long RTT flows will essentially
   starve, unless scalable congestion controls comply with this
   requirement.

   The RTT bias in current Classic congestion controls works
   satisfactorily when the RTT is higher than typical, and L4S does not
   change that.  So, there is no additional requirement for high RTT L4S
   flows to remove RTT bias - they can but they don't have to."


This uses the term "typical RTT", is this the same typical RTT as used in https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-13:


"Expected typical RTT, which can be used to determine the queuing
      delay of the Classic AQM at its operating point, in order to
      prevent typical lone flows from under-utilizing capacity.  For
      example:

      *  for the PI2 algorithm (Appendix A) the queuing delay target is
         set to the typical RTT;"

With typical RTT defaulting to 15 ms

"12:   target = RTT_typ            % PI AQM Classic queue delay target"
"For link rates from 4 - 200 Mb/s, a
   target RTT of 15ms and a maximum RTT of 100ms, it has been verified
   through extensive testing that Tupdate=16ms (as recommended in
   [RFC8033]) is sufficient."



So is the " typical RTTs" mentioned in draft-ietf-tsvwg-ecn-l4s-id-12 the same typical RTT as in draft-ietf-tsvwg-aqm-dualq-coupled-13?


If no, why are you using the same nomenclature for two different things in the same set of internet drafts?

If yes, how do you envision protocol designers to understand that the typical RTT value they need to pick really does not depend on the actual expected RTT for the typical network path they expect, but rather that this number needs to match the maximum configuration value of all L4S AQMs on the expected path?

In any way you should fix the ambiguity one way or the other.


Best Regards
	Sebastian


P.S.: @Bob, how do you reconcile your typical RTT definition with the following description in draft-ietf-tsvwg-aqm-dualq-coupled-13:
"The name 'PI' represents the fact that the second
   factor (how fast the queue is growing) is _P_roportional to load
   while the first is the _I_ntegral of the load (so it removes any
   standing queue in excess of the target)."

Where the last sentence clearly indicates what target specifies, namely the acceptable standing queue and not some mystical RTT value. But this mail is primarily concerned in clearing up what "typical RTTs" means in draft-ietf-tsvwg-ecn-l4s-id-12, trying to fix draft-ietf-tsvwg-aqm-dualq-coupled-13 is another kettle of fish.