> On 24 May, 2021, at 4:09 pm, Livingood, Jason via Bloat
> <bloat@lists.bufferbloat.net> wrote:
>
> I’m looking for opinions here re bloat-busting techniques like AQM in the
> context of network neutrality (NN). The worry I have is whether some
> non-technical people will misunderstand how AQM works & conclude that
> implementing it may violate NN because it would make interactive traffic
> perform better than it does today. That is true of course – it’s a design
> goal of AQM, but non-interactive traffic performs as well as it always has –
> it is not disadvantaged.
>
> Maybe the worries I have heard just points out the need for more
> education/awareness about what delay is and why things like AQM are not
> prioritization/QoS? I appreciate any thoughts.
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.
It's worth digging into the details a bit to solidify the message for a broader
range of audiences. You might start with my recently published Informational
draft discussing different types of latency:
https://datatracker.ietf.org/doc/html/draft-morton-tsvwg-interflow-intraflow-delays-00
I'll note in passing that AQM can be used as part of a system that would, in
fact, violate Net Neutrality. It's important to distinguish the effects caused
by different parts of the system, so that a Net-Neutral system can be obtained
by deleting just the parts that are incompatible with it. Current indications,
for example, are that L4S would fall under that definition, since it gives a
strong throughput priority to traffic carrying its identifier.
Without an AQM or FQ system at the bottleneck, interactive traffic is at the
mercy of any competing traffic as to how much delay it will suffer in the
queue. Non-interactive traffic seeks to keep that queue full in order to
maximise throughput, with latency being considered unimportant. If the queue
size is chosen carefully, the damage can be limited to some extent, but there
is a limit to how much a buffer can be shrunk before it starts reducing
throughput as well. In short, it is not possible to treat both types of
traffic equally well with a dumb FIFO; you must favour one or the other, and
historically it was throughput-sensitive applications that won that debate. I
think there is a little bit more awareness of right-sizing buffers these days,
but that can still easily lead to hundreds of milliseconds of unnecessary delay
to interactive traffic, which is difficult to tolerate.
By contrast, when you implement both AQM and FQ at the bottleneck, interactive
traffic is no longer affected by competing traffic at all, as long as they use
less than their "fair share" of available throughput capacity. When that
threshold is exceeded, the AQM will start working to inform them that they're
sending too fast, and the FQ will regulate the flow so that it *is* a fair
share that it consumes. This "fair share" metric has a number of different
reasonable definitions, but it should not be confused with a so-called "fair
usage policy"; it only kicks in when all the capacity on the link is already in
use.
You can also implement *just* AQM at the bottleneck. In this case the benefit
seen by interactive traffic is somewhat diluted, because all traffic goes
through the same queue in FIFO order. The AQM simply tells traffic to slow
down if the queue shows signs of filling up. This leaves the queue still able
to handle bursts of traffic (which are the main concern for throughput), while
minimising the delay since the queue does not sit constantly full. An
"Approximate Fairness" AQM also dynamically steers AQM signalling towards
traffic that contributes the most to congestion, leaving lighter and
interactive traffic alone.
Alternatively, you could implement *just* FQ, although this is usually seen as
the more difficult component of the two to implement at high speed and/or large
scale. This would simply hold bulk traffic to its "fair share", and keep it
out of the way of interactive traffic, without also reducing the delay to the
bulk traffic flows. I would suggest that if you implement FQ, you can also
usually implement AQM on top with little difficulty.
Please do ask for further clarification if that would be helpful.
- Jonathan Morton
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
