[Codel] [RFC PATCH] codel: ecn mark at target
eric.dumazet at gmail.com
Sat Aug 4 13:21:22 EDT 2012
On Sat, 2012-08-04 at 15:38 +0200, Richard Scheffenegger wrote:
> My 0.02 EUR:
> mark every packet with a sojourn time above target is OK.
> 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.
More information about the Codel