[tsvwg] L4S protocol requirements clarification question

[Sebastian Moeller <[e-mail]>]

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.