Jonathan Morton <chromatix99@gmail.com> wrote:
    > I'm pleased to help with education in this area.  The short and
    > simplistic answer would be that AQM treats all traffic going through it
    > equally; the non-interactive traffic *also* sees a reduction in
    > latency; though many people won't viscerally notice this, they can
    > observe it if they look closely.  More importantly, it's not necessary
    > for traffic to make any sort of business or authentication arrangement
    > in order to benefit from AQM, only comply with existing,
    > well-established specifications as they already do.

    > If the traffic supports ECN, the AQM can use that instead of packet
    > drops for signalling, which tends to actually *reduce* packet loss in
    > bulk transfers, compared to simply bouncing off the tail end of a dumb
    > FIFO.  Reduced latency would already make recovering from these losses
    > easier for the transport, but eliminating them entirely means that the
    > application receives a completely smooth delivery, with no sudden
    > pauses and jumps caused by the recovery process.

So it seems that it be fair to say that by reducing the latency, and finding a more
reasonable bandwidth*delay value, the AQM allows non-interactive traffic to
make do with less buffering.  This improves memory utilitization on the
receiver (the viewer), but perhaps more importantly, might it also improve
memory ultilization on the sender by allowing sent data to be purged faster.

Could this reduce the cost of OTT streaming services?
Maybe the savings is insignificant for a small service, but could it be
substantial for larger services?  (there is a media spin to avoid here)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [