David Lang <da...@lang.hm> wrote: > > re: gaming ECN > > Programmers are going to game ECN to their advantage (or at least to their > perceived advantage)
Some programmers will, no doubt... > There are three ways to mark flows as congested (Note any real path will likely have a mixture of these...) > 1. at the same level that you drop packets and then drop the packets at > this level (why bother) Many nodes do this today, simply by ignoring ECN-capable marking. > 2. at the level that you drop packets for non-ECN flows, you mark This _is_ the prescribed way to implement ECN today. > and allow ECN flows to continue Without deep-packet-inspection and saving _considerable_ state, no node can "allow" or "disallow" a particular flow to continue. Thus essentially no nodes try to "disallow" flows -- they merely provide signals of congestion. > 3. at a level below the point that you drop packets for all flows, you mark > ECN flows as congested This is what we have been talking about -- claiming it could result in better signals. > If you do #2, then flows with ECN effectively get priority over flows > without ECN It's not "priority". It's an occasional packet which gets through instead of being dropped. > (as you don't actually force them to back off, you are just asking > them to) We're not even "asking them" -- we're providing a signal. We _can't_ force them to back off. A not-ECN-capable flow could achieve the same result with Forward- Error-Correction tactics: include enough redundancy to regenerate all lost packets, and also decline to back off the sending rate. > Programmers will mark everything with ECN and not back off Perhaps some will. Certainly others will use FEC and not back off. So what? > If you do #3, then flows with proper ECN yield to flows without ECN, As ECN is defined today, indeed they will. > giving effective priority to flows without ECN We are not (yet) proposing any particular mechanism for ECN-marking at an earlier congestion status. If we do sometime propose a mechanism, this will serve as an incentive to upgrade to it. > Programmers will not use ECN as it puts their traffic at a disadvantage Programmers will use ECN when it offers them an advantage. In some cases, reducing packet loss _is_ that advantage; and backing off the sending rate is perfectly acceptable. In the future we may define algorithms that encourage stopping the exponential increase in sending rate without asking for a radical reduction in sending rate at the first ECN mark. There are types of traffic which would find that tradeoff _very_ attractive. But that's out of scope for us in this document -- just as any attempt to force flows to back off is out of scope. > If everyone uses ENC and backs off properly, then #3 is better as you > don't have the delays caused by re-sending packet. Thank you. > But in a mixed environment, ECN is going to be gamed one way or the other. So what? (BTW, I'd ask that same "So what?" for any problems of gaming not-ECN-capable traffic.) I would support explaining the problems you see; but I can't see abandoning the effort because you see problems. -- John Leslie <j...@jlc.net> _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
