Re: [Cake] cobalt, compared

[Dave Taht <dave.taht@gmail.com>]

[-- 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 --]