Re: [Cake] [Codel] Proposing COBALT

[Jonathan Morton <chromatix99@gmail.com>]

> On 4 Jun, 2016, at 20:49, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
> ECN (as in RFC 3168) is well known to be trivially exploited by peers
> pretending to be ECN ready, but not reacting to feedbacks, only to let
> their packets traverse congested hops with a lower drop probability.

In this case it is the sender cheating, not the receiver, nor the network.  ECN Nonce doesn’t apply, as it is designed to protect against the latter two forms of cheating (and in any case nobody ever deployed it).

Given that it’s *Valve* doing it, we have a good chance of convincing them to correct it, simply by explaining that it has an unreasonable effect on network latency and therefore game performance while Steam is downloading in the background.  This is especially pertinent since several of Valve’s own games are notoriously latency-sensitive FPSes.

COBALT should turn out to be a reasonable antidote to sender-side cheating, due to the way BLUE works; the drop probability remains steady until the queue has completely emptied, and then decays slowly.  Assuming the congestion-control response to packet drops is normal, BLUE should find a stable operating point where the queue is kept partly full on average.  The resulting packet loss will be higher than for a dumb FIFO or a naive ECN AQM, but lower than for a loss-based AQM with a tight sojourn-time target.

For this reason, I’m putting off drafting such an explanation to Valve until I have a chance to evaluate COBALT’s performance against the faulty traffic.

 - Jonathan Morton