[aqm] Gaming ECN

[John Leslie <[e-mail]>]

David Lang <[e-mail]> 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 <[e-mail]>