[Bloat] number of home routers with ingress AQM

[Ryan Mounce]

On Wed, 3 Apr 2019 at 00:05, Sebastian Moeller <moeller0 at gmx.de> wrote:
>
>
>
> > On Apr 2, 2019, at 15:15, Ryan Mounce <ryan at mounce.com.au> wrote:
> >
> > On Tue, 2 Apr 2019 at 22:08, Sebastian Moeller <moeller0 at gmx.de> wrote:
> >>
> >> I just wondered if anybody has any reasonable estimate how many end-users actually employ fair-queueing AQMs with active ECN-marking for ingress traffic @home? I am trying to understand whether L4S approach to simply declare these as insignificant in number is justifiable?
> >
> > L4S people are concerned by RFC 3168 / "classic" ECN bottlenecks
> > *without* fq.
>
>         I know, but I believe that they misunderstand the issues resulting from post-bottleneck shaping, like ingress shaping on the remote side of the true bottleneck. The idea seems that sending at too high a rate is unproblematic if the AQM can simply queue up these packets and delay them accordingly. But in the ingress shaper case these packets already traversed the bottleneck and aone has payed the bandwidth price to hoist them to the home, delaying or even dropping on the AQM side will not magically get the time back the packets took traversing the link.

My understanding is that with an AQM performing RFC 3168 style ECN
marking, the L4S flows will build a standing queue within their flow
queue before the AQM starts ECN marking. At this point the L4S flow
will be less responsive to marks with a linear (?) decrease rather
than treating it like loss (multiplicative decrease), however the AQM
will just keep on marking to keep in in check. The fq shaper will
continue to isolate it from other flows at the bottleneck and enforce
fairness between flows (or in the case of an ingress shaper after the
true bottleneck, continue to selectively apply drops/marks that
effectively 'nudge' flows towards fairness).

If there's no fq and there is RFC 3168 style ECN marking, the L4S
flows assume that they're receiving aggressive DCTCP-style marking,
respond less aggressively to each mark, and will starve conventional
Reno friendly flows. L4S people are relying on there being almost no
such bottlenecks on the internet, and to be honest I think this is a
fair assumption. The most deployed single queue AQM may be PIE as
mandated by DOCSIS 3.1, which had ECN marking disabled before the
whole DualQ/L4S thing. Bob Briscoe thinks the main concern is people
that have found old Cisco routers with RED and re-commissioned them...

As L4S flows would still be still be getting ECN marked in either case,
there would be no dropping of packets that have already traversed the
bottleneck in order to signal congestion. So long as there is fq to
enforce fairness, I can't see any problem.

Sure, signalling congestion without loss doesn't mean that the packets
haven't already spent more than their fair share of time at the
previous bottleneck. This is a more general problem with shaping
ingress further downstream from the true bottleneck - and I don't see
that it's any worse here than with any other TCP overshooting during
slow start.

There are certainly more real threats such as Akamai's FAST TCP. It's
like BBR in that it attempts to detect and respond to congestion based
on queuing latency, and tries to ignore low levels of random packet
loss that don't occur due to congestion. Their implementation
definitely presents issues for ingress shaping:
https://forums.whirlpool.net.au/thread/2530363

I saw that thread years ago, and then eventually saw the issue for
myself after changing ISP. Suddenly Windows Update was downloading
from my ISP's embedded Akamai cache using FAST TCP, and was
effectively unresponsive to cake's ingress shaping, instead filling
the queue in my ISP's BNG.

Fact is... ingress shaping is a hack. The real problem needs to be
solved in the BNG, in the CMTS, in the DSLAM, etc. L4S is just one
proposal and of course it deserves scrutiny before gobbling up the
precious ECT(1) codepoint, however it seems to have some traction with
vendors and a chance at wide deployment with a view to address address
exactly this problem *at* the bottleneck. For that, it also deserves
consideration.

>         Why do I care, because that ingress shaping setup is what I use at home, and I have zero confidence that ISPs will come up with a solution to my latency desires that I am going to be happy with... And what I see from the L4S mixes light with a lot of shadows.
>
>
> > I don't think there would be any such ingress shapers
> > configured on home gateways. Certainly not by anyone on this list...
> > anyone running non-fq codel or flowblind cake for ingress shaping?
>
>         As stated above, I believe fq to not be a reliable safety valve for the ingress shaping case.

-Ryan