Subject: Re: [iccrg] DC queue in time vs bytes

From: Toerless Eckert <[email-masked]>
Date: Fri, 13 Apr 2018 01:07:17 +0200

Bob:

I just randomnly stumble across this and actually already
had a question about this in another WG:

Lets assume i set up a link with two Weighted fair queues,
queue one with 95% of the link bandwidth and queue two with 5% of
the link bandwidth. I now want to define the queue size
in time, like e.g.: 10 msec for queue 1 and 20 msec for queue 2.

I can see the good intention when the link rate changes
that the queue size can nicely be updated, but i do not
understand how the queue size would work in the face
of different loads.

Lets assume the queue size in bytes is actually calculated
from the time value based on the assumed weight size vs. overall
link bandwidth. This will work fine when boh queues have
elastic traffic and both go to their max.

But what happens if queue one has lets say only 5% of
link bandwidth and queue two takes up all the remaining
link bandwidth. That would make the effective rate
through queue 19 times higher than the assumed rate
when converting time to bytes and therefore give me
effectively only 1 msec for this queue load.

Obviously, solutions such as virtual
queues with a shared buffer space across all queues on a
link and determing the time-length of a queue based
on the age of the top-of-queue packet could solve this, but
i would be very positively surprised if something like this
would exist in actual products..

Any insight ?

Cheers
    toerless

On Fri, Mar 23, 2018 at 10:20:43PM +0000, Bob Briscoe wrote:
> Yuchung,
> 
> As requested,
> Enabling ECN in Multi-Service Multi-Queue Data Centers <https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/bai>,
> NSDI'16
> Enabling ECN over Generic Packet Scheduling
> <http://doi.acm.org/10.1145/2999572.2999575>, CoNEXT'16
> 
> We wrote the history of the idea of using time instead of bytes in our PI2
> paper <http://www.bobbriscoe.net/pubs.html#pi2> (Related Work section).
> CoDel certainly introduced the sojourn time mechanism, but not the use of
> time:
> 
> "Actually,
> as far back as 2002, Kwon and Fahmy [24] had advised
> that the queue should be measured in units of time.
> Also, in 2003, Sågfors /et al/ had modified the Packet
> Discard Prevention Counter (PDPC+ [31]) algorithm
> by converting queue length to queuing delay to cope
> with the varying link rate of 3G wireless networks."
> 
> 
> 
> Bob
> 
> @Inproceedings{Bai16:ECN_GPS,
>   Title                    = {{Enabling ECN over Generic Packet
> Scheduling}{}},
>   Author                   = {Bai, Wei and Chen, Kai and Chen, Li and Kim,
> Changhoon and Wu, Haitao},
>   Booktitle                = {Proc. Int'l Conf Emerging Networking
> EXperiments and Technologies},
>   Year                     = {2016},
>   Address                  = {New York, NY, USA},
>   Pages                    = {191--204},
>   Publisher                = {ACM},
>   Series                   = {CoNEXT '16},
>   Acmid                    = {2999575},
>   Doi                      = {10.1145/2999572.2999575},
>   ISBN                     = {978-1-4503-4292-6},
>   Keywords                 = {aqm, datacenter networks, ecn},
>   Location                 = {Irvine, California, USA},
>   Numpages                 = {14},
>   Owner                    = {RJB},
>   Timestamp                = {2016.12.19},
>   Url                      = {http://doi.acm.org/10.1145/2999572.2999575}
> }
> 
> @Inproceedings{Bai16:MQ-ECN,
>   Title                    = {{Enabling ECN in Multi-Service Multi-Queue
> Data Centers}{}},
>   Author                   = {Wei Bai and Li Chen and Kai Chen and Haitao
> WuHaitao},
>   Booktitle                = {13th USENIX Symposium on Networked Systems
> Design and Implementation (NSDI 16)},
>   Year                     = {2016},
>   Address                  = {Santa Clara, CA},
>   Month                    = mar,
>   Pages                    = {537--549},
>   Publisher                = {USENIX Association},
>   Abstract-url             = {https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/bai},
>   ISBN                     = {978-1-931971-29-4},
>   Owner                    = {RJB},
>   Timestamp                = {2016.06.10},
>   Url                      =
> {https://www.usenix.org/system/files/conference/nsdi16/nsdi16-paper-bai.pdf}
> }
> 
> @Inproceedings{DeSchepper16a:PI2,
>   Title                    = {{PI\(^2\) : A Linearized AQM for both Classic
> and Scalable TCP}{}},
>   Author                   = {De Schepper, Koen and Bondarenko, Olga and
> Tsang, Ing-Jyh and Briscoe, Bob},
>   Booktitle                = {Proc. ACM CoNEXT 2016},
>   Year                     = {2016},
>   Address                  = {New York, NY, USA},
>   Month                    = dec,
>   Pages                    = {105--119},
>   Publisher                = {ACM},
>   Abstract-url             =
> {\url{http://www.bobbriscoe.net/pubs.html#PI2}},
>   Acmid                    = {2910633},
>   Affiliation              = {1,4:Simula; 2,3: Nokia Bell-Labs},
>   Articleno                = {33},
>   ISBN                     = {978-1-4503-4297-1},
>   Keywords                 = {Data Communication, Networks, Internet,
> Performance, Latency, Congestion Control, Congestion Avoidance, QoS,
> Algorithms, Design, AQM, TCP, Analysis, Scaling, Evaluation},
>   Owner                    = {RJB},
>   Timestamp                = {2016.10.04}
> }
> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 13 Apr 2018 11:45:41 +0200

> effectively only 1 msec for this queue load.

Yeah, this is inherent to estimating queueing time based on bandwidth
and queue size: You kind of need to know the instantaneous values of
both, which can be a problem if both vary wildly.

This is the reason why CoDel uses timestamping: This always give you the
*actual* queueing time, regardless of how the link characteristics vary.
No estimation needed :)

-Toke