[Ecn-sane] robustness against attack?

[Sebastian Moeller]

Hi Mikael,



> On Mar 25, 2019, at 08:16, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
> On Sun, 24 Mar 2019, Sebastian Moeller wrote:
> 
>> From my layman's perspective this is the the killer argument against the dualQ approach and for fair-queueing, IMHO only fq will be able to
> 
> Do people on this email list think we're trying to trick you when we're saying that FQ won't be available anytime soon on a lot of platforms that need this kind of AQM?

	I do not claim to speak for people on this list, but really just for myself.

> 
> Since there is always demand for implementations, can we get an ASIC/NPU implementation of FQ_CODEL done by someone who claims it's no problem?

	Out of my area of expertise and interests, sorry.

> 
> Personally I believe we need both. FQ is obviously superior to anything else most of the time, but FQ is not making itself into the kind of devices it needs to get into for the bufferbloat situation to improve, so now what?

	So, I have mostly given up on ISPs in this matter, there simply seems to be no economic incentive I can see for ISPs to spend any money to improve latency under load behavior of the typical choke points (access links, aggregation network, transit/peering connections). IMHO even the very company friendly LLLLS project does not really offer any noticeable incentives for ISPs to change, that is short of the ill-defined reordering tolerance there seems nothing in it that directly might affect an ISP's bottom line. I say ill-defined, as RACK does not seem to give the re-ordering resistance promises that the link-layer people would need (I would expect a minimum re-odering time independent of RTT for this to be useful for both sides).
	And I have seen how badly this line of reasoning played out with docsis 3.1's pie ... To recap, DOCSIS 3.1 rejected fq for a single queue aqm due to keeping CPE cost down to not hinder deployment at scale, but now DOCSIS3.1 is still not rolled-out at scale, and CPE's often sport dual-core intel atoms well capable of shaping at the 50-100 Mbps uplink speeds that ISPs offer (heck these should have enough punch to also run fq-AQM on the up to 1Gbps downlink of modern docsis-3.1 plans). In other words I fail to see how this line of reasoning was valid the last time around and I fail to see how this is going to play out differently this time around. I do see an opportunity for ISPs to offer "gamer-ready" low latency router-modems that do all fancy AQM on the CPE side, as a special item at a extra cost this might actually work economically... Keep the core network as latency agnostic as it is now, but sell latency optimized AQM to interested customers, and then pass the cost for the required hardware to perform this shaping to the same customer that will profit from it. That at least looks like something that ISP might earn something from and that will make customers happy (aka win-win).

> 
> Claiming to have a superior solution that is too expensive to go into relevant devices, is that proposal still relevant as an alternative to a different solution that actually is making itself into silicon?

	So I applaud adding at least a reasonably competent single queue AQM to ISP gear, but from my vantage point this will not magically make everything snappy and well for latency conscious end-users and hence will not replace competent AQM at the client side except that is might serve as a "backstop" to improve the worst case latency-under-load increase (even though LLLLS's worst case of 250ms is not that impressive).

> 
> Again, FQ superior, but what what good is it if it's not being used?

	Good point, but I want to avoid that something like LLLLS with the proposed idea of a heuristic how to detect RFC-compliant ECN markig AQMs will destroy the well-tuned latency-under-load performance of the ingress shaper at my home that uses fq and conpetent AQM to keep latency at bay even at saturating loads. Again, I do not want a half-arsed, optimised for low-cost (let's face it this all boils down to money and who pays), solution like LLLLS to screw things up. I note that this hinges up the leaky classifier proposed and is not an argument against LLLLS and its goals.

> 
> We need to have this discussion and come up with a joint understanding of the world, otherwise we're never going to get anywhere.

	Fair enough. I note again, I am from outside the field and just represent an opinionated end-point and I approach the issue from that vantage point, please do not expect me to reason for ISPs where I have no reliable insight in the economic or engineering challenges.

Best Regards
	Sebastian

> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se