David Lang <[email protected]> wrote: > On Mon, 13 Apr 2015, Bob Briscoe wrote: > >> I think your conception of how ECN works is incorrect. You describe ECN as >> if the AQM marks one packet when it drops another packet. You say that the >> ECN-mark speeds up the retransmission of the dropped packet. On the >> contrary, the idea of classic ECN [RFC3168] is that the ECN marks replace >> the drops. In all known testing (except pathological cases), classic ECN >> effectively eliminates drops for all ECN-capable packets. > > That's what I thought, and if that was the case,
What does "that" refer to -- I honestly can't tell from your text. (We have an awful lot of talking past each other when we talk ECN: it would really help to be as clear as possible.) > then marking packets as ECN-capable would mean that they would have an > advantage over non-ECN packets (by not getting dropped, so getting a > higher share of bandwidth) I wish I could go back in time an excise every phrase saying "same as a packet drop" from the ECN RFCs. > that's what the gaming ECN thread was about, and if I understood the > responses, I was being told that marking packets as ECN-capable, but not > slowing down (actually responding to ECN) would not let an application get > any advantage because the packets would just end up getting dropped anyway, > since marking and dropping happen at the same level, even on ECN-capable > flows. No, I don't think any of us were saying that. A few of us _were_ saying that abuse like that is a small percentage of the abuse where the sender simply doesn't reduce the sending rate if packet loss is detected. And several folks _did_ say that it was important to have the marking and dropping threshholds the same _and_ the reaction to marking the same as the reaction to dropping be the same "so that neither would suffer in comparison to the other". (They are wrong, BTW, but most of us just let this canard die down.) > If the packets are just marked, but not dropped, then the ECN-capable flows > will occupy a disproportinate share of the available buffer space, since > they just get marked instead of dropped. True. But so what? What do you want to do about it? (That's my trademark question, BTW.) If you are the node experiencing congestion, and your buffer is full, you absolutely should drop the marked packet. No disagreement there. (This can happen, BTW, in PIE, which marks packets as the enter the buffer; and the buffer may fill before they can be sent.) But if your buffer isn't even close to full, what's wrong with ECN capable packets using a larger share of the buffer? If they go to a responsive flow, the reaction will be quicker than if they were dropped. Of course, if they go to a non-responsive flow, they would get a slight advantage, but why is that _your_ concern? And there's really nothing you can do to counter the advantage that doesn't break the ECN paradigm for responsive flows. If instead, you are a node later on the path, there's nothing wrong with dropping ECN packets with Congestion-Experienced marks _when_ you need to drop packets. But there's no reason to "punish" them for having occupied a "disproportionate share" of somebody else's buffer. It would be much better if we could think in terms of ECN-marking _well_before_ there is any need to drop packets because the buffer is full; and treating any "advantage" this might give them an an incentive for more flows to enable ECN. One of the things I'm quite sure Bob Briscoe is thinking -- but not writing -- is that he believes ECN can solve a lot of the problems he named _if_ the ECN marking occurs at a lower threshhold than packet drop. We are _not_ chartered to "fix ECN" in this WG: so that discussion doesn't really belong in this thread; but you and Bob are unlikely to communicate fully if you ignore that possibility. Hope this helps... -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
