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
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
