[Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

[Michael Welzl]

> On 20. mar. 2015, at 19.25, David Lang <david at lang.hm> wrote:
> 
> On Sat, 21 Mar 2015, Steinar H. Gunderson wrote:
> 
>> On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote:
>>> 1. If you mark packets as congested if they have ECN and drop them
>>> if they don't, programmers will mark everything ECN (and not slow
>>> transmission) because doing so gives them an advantage over
>>> applications that don't mark their packets with ECN
>> 
>> I'm not sure if this is actually true. Somehow TCP stacks appear to be tricky
>> enough to mess with that the people who are capable of gaming congestion
>> control algorithms are also wise enough not to do so. Granted, we are seeing
>> some mild IW escalation, but you could very well make a TCP that's
>> dramatically unfair to everything else and deploy that on your CDN, and
>> somehow we're not seeing that.
> 
> It doesn't take deep mucking with the TCP stack. A simple iptables rule to OR a bit on as it's leaving the box would make the router think that the system has ECN enabled (or do it on your local gateway if you think it gives you higher priority over the wider network)
> 
> If you start talking about ECN and UDP things are even simpler, there's no need to go through the OS stack at all, craft your own packets and send the raw packets
> 
>> (OK, concession #2, “download accelerators” are doing really bad things with
>> multiple connections to gain TCP unfairness, but that's on the client side
>> only, not the server side.)
>> 
>> Based on this, I'm not convinced that people would bulk-mark their packets as
>> ECN-capable just to get ahead in the queues.
> 
> Given the money they will spend and the cargo-cult steps that gamers will do in the hope of gaining even a slight advantage, I can easily see this happening
> 
>> It _is_ hard to know when to
>> drop and when to ECN-mark, though; maybe you could imagine the benefits of
>> ECN (for the flow itself) to be big enough that you don't actually need to
>> lower the drop probability (just make the ECN probability a bit higher),
>> but this is pure unfounded speculation on my behalf.
> 
> As I said, there are two possibilities
> 
> 1. if you mark packets sooner than you would drop them, advantage non-ECN

Agreed, with a risk of starvation of ECN flows as we've seen - this is not easy to get right and shouldn't be "just done somehow".


> 2. if you mark packets and don't drop them until higher levels, advantage ECN, and big advantage to fake ECN

Same level as you would normally drop is what the RFC recommends. Result: advantage ECN mostly because of the end-to-end effects I was explaining earlier, not because of the immediate queuing behavior (as figure 14 in https://www.duo.uio.no/handle/10852/37381 shows). "Big advantage to fake ECN" is the part I don't buy; I explained in more detail in the AQM list.

Cheers,
Michael