[Cake] cobalt, compared

[Cake] cobalt, compared

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]

https://www.tu-ilmenau.de/fileadmin/Bereiche/IA/vsbs/Publikationen/2024/SSK_NOMS24_AdaptiveAQM_Authors-version.pdf


-- 
https://www.linkedin.com/feed/update/urn:li:activity:7203400057172180992/
Donations Drive.
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 731 bytes --]

Re: [Cake] cobalt, compared

[Jonathan Morton]

> On 14 Jun, 2024, at 2:40 am, Dave Taht via Cake <cake@lists.bufferbloat.net> wrote:
> 
> https://www.tu-ilmenau.de/fileadmin/Bereiche/IA/vsbs/Publikationen/2024/SSK_NOMS24_AdaptiveAQM_Authors-version.pdf

I don't understand their test methodology.  I mean that literally.

Their results indicate queue delays in the region of one whole second.  This is wildly different from the target delays of any of the AQMs tested.  In fact, their results for COBALT are above the trigger for BLUE activity (which they also helpfully listed in their configuration table).  One obvious conclusion is that COBALT's lower queue delays and higher loss rates in their results are precisely due to relying on the BLUE component.  But that is most certainly not the intended operating regime for COBALT - BLUE is provided as a failsafe, not as a primary congestion signalling mechanism.

They state a link rate of 2Gbps, and a variety of flow rates, the highest of which is 10Mbps.  Even if we multiply the latter by the number of clients (100), the 2Gbps link is not saturated.  If there's a separate flow between each client-server Cartesian product, and the clients are each limited to a 10Mbps link with its own AQM instance, then we should expect AQM activity to be capable of keeping the queue delay down to about 20ms (5x a small number of MTUs), which is 50x better than their typical reported results.

I can only conclude that, for whatever reason, they have constructed a traffic scenario (the details of which are not adequately reported in the paper) which induces an extreme level of congestion, which of course the conventional AQMs have some trouble with handling (but COBALT does better on, due to BLUE activity).  They then introduce their own AQMs to this scenario, and report that they do better on a couple of metrics (but are still very bad on the others).

Overall, this paper does not provide any information of interest.

 - Jonathan Morton

Re: [Cake] cobalt, compared

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

Thank you. I too was puzzled but didn't take the time to delve deeper.



On Fri, Jun 14, 2024 at 4:05 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 14 Jun, 2024, at 2:40 am, Dave Taht via Cake <
> cake@lists.bufferbloat.net> wrote:
> >
> >
> https://www.tu-ilmenau.de/fileadmin/Bereiche/IA/vsbs/Publikationen/2024/SSK_NOMS24_AdaptiveAQM_Authors-version.pdf
>
> I don't understand their test methodology.  I mean that literally.
>
> Their results indicate queue delays in the region of one whole second.
> This is wildly different from the target delays of any of the AQMs tested.
> In fact, their results for COBALT are above the trigger for BLUE activity
> (which they also helpfully listed in their configuration table).  One
> obvious conclusion is that COBALT's lower queue delays and higher loss
> rates in their results are precisely due to relying on the BLUE component.
> But that is most certainly not the intended operating regime for COBALT -
> BLUE is provided as a failsafe, not as a primary congestion signalling
> mechanism.
>
> They state a link rate of 2Gbps, and a variety of flow rates, the highest
> of which is 10Mbps.  Even if we multiply the latter by the number of
> clients (100), the 2Gbps link is not saturated.  If there's a separate flow
> between each client-server Cartesian product, and the clients are each
> limited to a 10Mbps link with its own AQM instance, then we should expect
> AQM activity to be capable of keeping the queue delay down to about 20ms
> (5x a small number of MTUs), which is 50x better than their typical
> reported results.
>
> I can only conclude that, for whatever reason, they have constructed a
> traffic scenario (the details of which are not adequately reported in the
> paper) which induces an extreme level of congestion, which of course the
> conventional AQMs have some trouble with handling (but COBALT does better
> on, due to BLUE activity).  They then introduce their own AQMs to this
> scenario, and report that they do better on a couple of metrics (but are
> still very bad on the others).
>
> Overall, this paper does not provide any information of interest.
>
>  - Jonathan Morton



-- 
Artists/Musician Campout Aug 9-11
https://www.eventbrite.com/e/healing-arts-event-tickets-928910826287
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 3204 bytes --]