Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,


> On Nov 19, 2019, at 11:30, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> Hi Michael
> Fair point, or perhaps in this discussion, I should use another word than "fair" to avoid confusion 😊
> 
> Yes. I know the paper discussed CoDel, what I wanted to point out however that CoDel has its own share of issues related to link underutilization at higher RTTs, meaning that the 5ms threshold is not good enough in all cases. My interpretation is that for classic traffic you need to set the thresholds differently depending on what RTT you expect your e2e traffic to experience.

	[SM] This is made pretty explicit in the codel rfc (https://tools.ietf.org/html/rfc8289) in the sections:

"4.2.  Setting INTERVAL


   The INTERVAL value is chosen to give endpoints time to react to a
   drop without being so long that response times suffer.  CoDel's
   estimator, TARGET, and control loop all use INTERVAL.  Understanding
   their derivation shows that CoDel is the most sensitive to the value
   of INTERVAL for single long-lived TCPs with a decreased sensitivity
   for traffic mixes.  This is fortunate, as RTTs vary across
   connections and are not known a priori.  The best policy seems to be
   to use an INTERVAL value slightly larger than the RTT seen by most of
   the connections using a link, a value that can be determined as the
   largest RTT seen if the value is not an outlier (use of a 95-99th
   percentile value should work).  In practice, this value is not known
   or measured (however, see Appendix A for an application where
   INTERVAL is measured).  An INTERVAL setting of 100 ms works well
   across a range of RTTs from 10 ms to 1 second (excellent performance
   is achieved in the range from 10 ms to 300 ms).  For devices intended
   for the normal terrestrial Internet, INTERVAL SHOULD have a value of
   100 ms.  This will only cause overdropping where a long-lived TCP has
   an RTT longer than 100 ms and there is little or no mixing with other
   connections through the link.


4.3.  Setting TARGET


   TARGET is the maximum acceptable persistent queue delay above which
   CoDel is dropping or preparing to drop and below which CoDel will not
   drop.  TARGET SHOULD be set to 5 ms for normal Internet traffic.

   The calculations of 
Section 3.2
 show that the best TARGET value is
   5-10% of the RTT, with the low end of 5% preferred.  Extensive
   simulations exploring the impact of different TARGET values when used
   with mixed traffic flows with different RTTs and different bandwidths
   show that below a TARGET of 5 ms, utilization suffers for some
   conditions and traffic loads; above 5 ms showed very little or no
   improvement in utilization.

   Sojourn times must remain above the TARGET for INTERVAL amount of
   time in order to enter the drop state.  Any packet with a sojourn
   time less than TARGET will reset the time that the queue was last
   below TARGET.  Since Internet traffic has very dynamic
   characteristics, the actual sojourn delay experienced by packets
   varies greatly and is often less than TARGET unless the overload is
   excessive.  When a link is not overloaded, it is not a bottleneck,
   and packet sojourn times will be small or nonexistent.  In the usual
   case, there are only one or two places along a path where packets
   will encounter a bottleneck (usually at the edge), so the total
   amount of queueing delay experienced by a packet should be less than
   10 ms even under extremely congested conditions.  This net delay is
   substantially lower than common current queueing delays on the
   Internet that grow to orders of seconds [NETAL2010] [CHARB2007].

   Regarding the roles of TARGET and the minimum-tracking INTERVAL, note
   that TARGET SHOULD NOT be increased in response to lower layers that
   have a bursty nature, where packets are transmitted for short periods
   interspersed with idle periods where the link is waiting for
   permission to send.  CoDel's estimator will "see" the effective
   transmission rate over an INTERVAL amount of time, and increasing
   TARGET only leads to longer queue delays.  On the other hand, where a
   significant additional delay is added to the intrinsic RTT of most or
   all packets due to the waiting time for a transmission, it is
   necessary to increase INTERVAL by that extra delay.  TARGET SHOULD
   NOT be adjusted for such short-term bursts, but INTERVAL MAY need to
   be adjusted if the path's intrinsic RTT changes."


Yes, you are correct that INTERVAL should be roughly matched to the observed RTT, but note that roughly here means roughly, so being off by a factor of 2 is not too problematic. TARGET however is simply a function of interval, I note again, that the derivation of TARGET from INTERVAL dependes on TCPs standard response pattern and hence should not be specific to CODEL or FQ_CODEL (this is why I proposed that as a stop-gap measure the dual queue AQM is tested with a reference queue delay value of 5 ms, but I digress).
	The same applies for PIE and other AQMs, the root cause seems to be that longer RTTs imply looser control loops and hence a disadvantage at competing with nimbler short RTT flows, which probably might be partially ameliorated, but probably is unfixable gerically (short of giving all control loops the worst case delay artificially).
But see Høiland-Jørgensen T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential setting. Computer Networks 89:90–106. (https://www.sciencedirect.com/science/article/pii/S1389128615002479) for a deeper exploration of how that interacts with different path lengths and fairness.

This is also orthogonal, to the failure of L4S reference scheduler to properly share bandwidth between the two traffic classes L4S recognizes. And I personally doubt that that is easily fixable inside the existing dual queue AQM/scheduler design, but am opn to be convinced otherwise by hard empirical data.



Best Regards
	Sebastian





> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Michael Welzl <[e-mail]>
>> Sent: den 19 november 2019 11:20
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=[e-mail]>
>> Cc: Holland, Jake <[e-mail]>; [e-mail];
>> <[e-mail]> Fairhurst <[e-mail]>; Ingemar
>> Johansson S <[e-mail]>
>> Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-
>> tsvwg-sce
>> 
>> JUST A CORRECTION  (*), because that was our work:
>> 
>>> FQ-CoDel is not problem free either see
>>> https://protect2.fireeye.com/v1/url?k=e91d5acb-b58f57d4-e91d1a50-
>> 0cc47
>>> ad93db4-16a1170b93824c3b&q=1&e=74431335-0146-453f-a47c-
>> fe14226bcc52&u=
>>> 
>> http%3A%2F%2Fdl.ifip.org%2Fdb%2Fconf%2Fnetworking%2Fnetworking201
>> 7%2F1570335770.pdf , which later on led to the alternate recommendations
>> in RFC8511, in other words the unfairness issues are to be addressed in the
>> endpoints.
>> 
>> We only evaluated CoDel, not FQ-CoDel, and this didn’t focus on fairness.
>> FQ_* is quite fair AFAIK  :-)
>> 
>> So… the unfairness issue wasn’t the argument in this paper that led to RFC
>> 8511.
>> 
>> Cheers,
>> Michael
>> 
>> ---
>> (*) the use of capitals here means: I am NOT a participant in this discussion,
>> OH MY GOD I am not, PLEASE don’t involve me!!!   … I’m merely correcting a
>> statement about our own earlier work.  I do enjoy watching the debate from
>> a safe distance, though.
>