[Codel] [RFC PATCH] codel: ecn mark at target

[Eric Dumazet]

On Sat, 2012-08-04 at 15:38 +0200, Richard Scheffenegger wrote:
> Hi,
> 
> My 0.02 EUR:
> 
> mark every packet with a sojourn time above target is OK.
> 

Thats insane.

> The reaction of the congestion controller to ECN marks need to be more 
> differentiated; ECN can deliver much more fine-grained information about the 
> current state of the network. If a congestion controller (e.g. legacy 3168 
> ECN TCP) chooses to overshoot in it's reaction, thats a problem for that 
> particular controller... But even if every packet of a window is marked, a 
> legacy TCP will only reduce cwnd once per window, reacting the same as is a 
> non-ECN had a single drop in that window...

Thats would maybe work if all flows were ECN and kind.

If you have a mix, then ECN flows are completely shut off. And I knew it
before doing any experiment.

What makes you think non ECN flows will drop at least one packet, while
we ECN mark ECN flow ? How is cwnd 'known' by Codel exactly ?

I did following experiment :

link with HTB limit of 100Mbit/s
One netperf TCP_STREAM to a non ECN enabled local target, duration 100s
One netpert TCP_STREAM to a ECN enabled local target, duration 100s

1) Current Codel implementation

non ECN target A : 50.55 Mbit/s   (4336 dropped packets)
ECN target B     : 45.86 Mbits/s (3239 ecn marks)

2) Patch to mark all ecn-enabled packets above 'target'

non ECN target A : 95.43 Mbit/s (2957 drops)
ECN target B    :  0.97 Mbit/s (2500 ecn marks)

Yes, you see how wrong this idea is : Almost all packets to host B
are marked, so throughput is horrible.

It seems few people really understood CoDel 'target'. When a link
is used, almost all packets are above target. Thats OK. If it was not
OK, why would we use the sqrt(count) at all, I wonder.

Codel intent is not to mark/drop _all_ packets above 'target'.

ECN intent is to replace a drop by a mark, not marking packets that
would not have been dropped at all if they were not ECN enabled.