Subject: [tsvwg] Technical review 4 on draft-ietf-tsvwg-aqm-dualq-coupled-08

From: David Pullen <[email-masked]>
Date: Tue, 18 Dec 2018 14:53:27 -0500

Hi Bob,

At the end of Appendix A, WRR is recommended over time-shifted FIFO, but no
real justification is given. Why is WRR recommended?

Thanks,
  - Dave

David Pullen
Distinguished Engineer  |  Wired Networking, Cable Modems
Broadcom

office: 678.475.3143  |  mobile: 678.477.4108  |  fax: 770.232.0211
4385 River Green Parkway  |  Duluth, GA 30096
[email-masked]   |   broadcom.com

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 21 Dec 2018 19:13:38 +0000

David,

OK, you're right that we don't do a good job of justifying this, other 
than hinting that WRR is already well-known.

I've recorded much more of the thinking behind this choice. I've also 
explained why the choice of WRR scheduler weight is not important, as 
follows (additions in green):

    o  A well-understood weighted scheduler such as weighted round robin
       (WRR) is recommended.  The scheduler weight for Classic should be
       low, e.g. 1/16.Note that the coupled congestion signal typically make L4S sources leave 
roughly equal per-flow capacity available for classic flows. So, if the 
weight is small, its exact value is unimportant because it does not 
normally determine capacity shares. The weight is only important to 
prevent unresponsive L4S traffic starving classic traffic.

    o  Alternatively, a time-shifted FIFO (TS-FIFO) could be used.  It
       works by selecting the head packet that has waited the longest,
       biased against the Classic traffic by a time-shift of tshift.  To
       implement time-shifted FIFO, the "if (scheduler() == lq )" test in
       line 3 of the dequeue code would simply be replaced by "if (
       lq.time() + tshift >= cq.time() )".  For the public Internet a
       good value for tshift is 50ms.  For private networks with smaller
       diameter, about 4*target would be reasonable.TS-FIFO is a very simple scheduler, but complexity might need to be 
added to address some deficiencies (which is why it is not recommended 
over WRR): * TS-FIFO does not fully isolate latency in the L4S queue 
from uncontrolled bursts in the Classic queue; * TS-FIFO is only 
appropriate if time-stamping of packets is feasible; * Even if 
time-stamping is supported, the sojourn time of the head packet is 
always stale. For instance, if a burst arrives at an empty queue, the 
sojourn time will only measure the delay of the burst once the burst is 
over, even though the queue knew about it from the start. At the cost of 
more operations and more storage, a 'scaled sojourn time' metric of 
queue delay can be used, which is the sojourn time of a packet scaled by 
the ratio of the queue sizes when the packet departed and arrived.

Bob

On 18/12/2018 19:53, David Pullen wrote:
> Hi Bob,
>
> At the end of Appendix A, WRR is recommended over time-shifted FIFO, 
> but no real justification is given. Why is WRR recommended?
>
> Thanks,
>   - Dave
>
> David PullenDistinguished Engineer  |  Wired Networking, Cable 
> ModemsBroadcomoffice:678.475.3143  | mobile:678.477.4108  | 
> fax:770.232.02114385 River Green Parkway  |  Duluth, GA 
> [email-masked] <mailto:[email-masked]>   | 
> broadcom.com <http://broadcom.com>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Dave Taht <[email-masked]>
Date: Mon, 24 Dec 2018 18:56:37 -0800

Bob Briscoe <[email-masked]> writes:

>       low, e.g. 1/16.  Note that the coupled congestion signal typically
>       make L4S sources leave roughly equal per-flow capacity available
>       for classic flows.  So, if the weight is small, its exact value is
>       unimportant because it does not normally determine capacity
>       shares.  The weight is only important to prevent unresponsive L4S
>       traffic starving classic traffic.

I note that the "fq" portion of fq_codel (RFC8290) has better min/max properties
than straight drr, as does qfq. 

I am saddened that there is seemingly no fq or aqm component intended for
"classic" flows in this design, as if it didn't need it.

The first deployment of fq_codel (free.fr's) had the following weighted
queue structure:

drr 1 priority fq_codel (diffserv markings)
drr 2 best effort fq_codel
drr 3 background fq_codel

and nearly the entire qos related deployment of this has essentially the
same structure, including sch_cake.

In deprioritizing "classic" to 1/16 the total possible flow volume, any
form of weighted fair queuing can be used, but I still don't know why
you wish to punish classic flows so much by eliding aqm and fq on those.

>       diameter, about 4*target would be reasonable.  TS-FIFO is a very
>       simple scheduler, but complexity might need to be added to address
>       some deficiencies (which is why it is not recommended over WRR):
>
>       *  TS-FIFO does not fully isolate latency in the L4S queue from
>          uncontrolled bursts in the Classic queue;
>
>       *  TS-FIFO is only appropriate if time-stamping of packets is
>          feasible;
>
>       *  Even if time-stamping is supported, the sojourn time of the
>          head packet is always stale.  For instance, if a burst arrives
>          at an empty queue, the sojourn time will only measure the delay
>          of the burst once the burst is over, even though the queue knew
>          about it from the start.  At the cost of more operations and
>          more storage, a 'scaled sojourn time' metric of queue delay can
>          be used, which is the sojourn time of a packet scaled by the
>          ratio of the queue sizes when the packet departed and arrived.
>
> Bob
>
>     At the end of Appendix A, WRR is recommended over time-shifted
>     FIFO, but no real justification is given. Why is WRR recommended?
>     
>     
>     
>     
>     
>     
>     
>     
>     
>     
>     
>     Thanks, 
>     - Dave
>     
>     
>         David Pullen Distinguished Engineer | Wired Networking, Cable
>     Modems Broadcom office: 678.475.3143 | mobile: 678.477.4108 | fax:
>     770.232.0211 4385 River Green Parkway | Duluth, GA 30096