Re: [aqm] Gaming ECN (again) (was: think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02)

[David Lang <[e-mail]>]

On Wed, 15 Apr 2015, Bob Briscoe wrote:

> 3) I will prove that it is as easy to game loss as it is to game ECN, first 
> considering sender cheating, then receiver cheating:

I think there is a key difference

cheating non-ECN requires changes to the TCP stack code

cheating ECN requires an iptables rule to zero out the ECN bit on received 
packets before they hit the TCP stack.

I've seen enough people doing cargo-cult network configs to 'improve 
gaming' (MTU 576 as one example) that I expect that if there is any noticable 
advantage for doing so, there will be a significant population doing so.

> 3a) Sender Cheating
> From the sender's point of view, the only difference between a loss and an 
> ECN mark is that it has to retransmit a loss. But that has nothing to do with 
> the rate it can go at. If it has been programmed to ignore congestion 
> feedback (and instead to go at a constant unresponsive rate{Note 2}), it is 
> as easy for it to ignore loss feedback as ECN feedback. See {Note 3} for an 
> example.
>
> 3b) Receiver Cheating
> * An ECN receiver can best fool an ECN-capable TCP sender into going faster 
> by only feeding back a small fraction of ECN marks.{Note 4}
> * A non-ECN receiver could fool a non-ECN TCP sender into going faster by 
> only revealing a small fraction of the losses. However, it would have to ACK 
> undelivered bytes, and most TCP-based apps won't work unless all bytes are 
> delivered.{Note 5}
>
> So it seems that it's easier for a receiver to game ECN than loss. However:
> * returning to the ECN case, the sender can validate the receiver by randomly 
> setting an ECN mark itself on a very small proportion of packets (probably 
> only on unusually high rate connections). Then if it doesn't see ECN feedback 
> on the ACK of any one of its self-inserted marks, it can close the 
> connection.

do any TCP stacks do this?

won't this cause the datarate to slow down, something that will seem 'bad' for 
the people who would need to code this (it will show up on benchmarks as random 
slowdowns, right?)

> In summary,
> * a sender can't game ECN any more easily than it can game loss.

I think it's more "there is a way to detect gaming ECN"

> * a receiver can only game ECN if the sender doesn't take measures to prevent 
> it.{Note 6}
>
>> 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.
>
> Nope.
>
> The arrival rates will be the same, whether or not ECN is used (see earlier). 
> And recall  that TCP drives the marking or loss probability at very small 
> fractions in all normal conditions.
>
> Example: if there are 10 flows in a 100Mb/s link, 5 ECN and 5 non-ECN, they 
> will all arrive at the buffer at 10Mb/s (all other factors being equal). 
> Then, if the loss or marking probability is 0.5%, the AQM will be marking but 
> not dropping 1 in 200 packets in the ECN flows whereas it would drop 1 in 200 
> from the non-ECN flows.
>
> So, assuming tail drop, if there were 399 packets in this buffer, on average 
> 200 would be ECN-capable (20 in each flow) with one marked; and 199 would be 
> non-ECN-capable (20 in each flow except one with 19). And one of those 199 
> would be a retransimssion from an earlier loss.
>
> [Of course, we would hope that there would be 4 packets in the buffer, not 
> 400. The proportions would still be the same on average. I merely used 399 to 
> avoid fractions of packets for the averages.]
>
>
> ===Footnotes===
>
> {Note 3} Examples to show source cheating is as easy with loss as ECN:
> * An ECN source sends at a constant unresponsive 90Mb/s through a 100Mb/s 
> bottleneck. In parallel some other responsive flows (say 10 non-ECN TCP 
> flows) squeeze themselves into the remaining 10Mb/s. They will cause 
> themselves (say) 0.5% loss probability, while the unresponsive flow will 
> experience 0.5% marking and zero loss.
> * A non-ECN source can just as easily send unresponsively at 90.5Mb/s as 
> 90Mb/s. The other flows will still drive loss to about 0.5%, which the 
> unresponsive flow will now experience as well. Nonetheless, after it 
> retransmits the 0.5% loss it still achieves goodput of about 90Mb/s.

well, sort of.

if the retransmissions are due to dropped packets, it may require retransmitting 
some packets that actually got through (depending on the link latency and rate 
of transmission, those added packets may not be acked before they also get 
retransmitted), this will waste some bandwidth

if the sender slows down, it may drop significantly below the 90Mb/s rate and 
have to ramp up to that rate again.

> {Note 4} Again, feeding back no marks at all would be naive, because it would 
> drive the bottleneck into overload, causing it to turn off ECN (and driving 
> the loss-rate over a cliff). A better strategy is to feedback only a small 
> proportion. Because TCP's rate depends on the square root of the congestion 
> probability, to download N times faster, the receiver should feed back only 
> about 1 in N^2 of the marks or losses. E.g. to go 90 times faster, feed back 
> 1 in 8100 marks (or losses).

that assumes that the raw sending rate is enough higher to drive the link into 
overload itself rather than just being enough higher to demand an unfair share 
of the link

you use the example of a 100Mb link with one app getting 90Mb and trying to get 
more.

Instead think of that same 100Mb link, but with 100 1Mb flows going over it. 
Would ignoring ECN feedback allow one app to get a 50Mb flow, squeezing the 
other apps to .5Mb each?

> {Note 5} There are two classes of apps that use TCP but can get away without 
> reliable delivery:
> i) Some streaming media apps are designed with a loss-tolerant encoding, so 
> they can use TCP but play out the media even if some retransmissions haven't 
> arrived yet (e.g. using a raw socket at the receiver).
> ii) In the specific case of HTTP, a hacked receiver can open another 
> connection to the same server and download the byte-ranges it needs to repair 
> the holes in the other connection.

the TCP stack will demand reliable delivery, even if the app doesn't. There 
isn't any provision for an app to use TCP but allow 'holes' in the data.

David Lang