On Wed, 3 Apr 2019 at 00:05, Sebastian Moeller <moell...@gmx.de> wrote: > > > > > On Apr 2, 2019, at 15:15, Ryan Mounce <r...@mounce.com.au> wrote: > > > > On Tue, 2 Apr 2019 at 22:08, Sebastian Moeller <moell...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat