> On 20. mar. 2015, at 19.25, David Lang <da...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
