[Codel] [RFC PATCH] codel: ecn mark at target
rscheff at gmx.at
Sun Aug 5 12:54:34 EDT 2012
----- Original Message -----
From: "Eric Dumazet" <eric.dumazet at gmail.com>
To: "Andrew McGregor" <andrewmcgr at gmail.com>
Cc: <codel at lists.bufferbloat.net>
Sent: Sunday, August 05, 2012 7:30 AM
Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target
> On Sat, 2012-08-04 at 20:06 -0700, Andrew McGregor wrote:
>> Well, thanks Eric for trying it.
>> Hmm. How was I that wrong? Because I was supporting that idea.
>> Time to think.
> No problem Andrew ;)
> Its seems ECN is not well enough understood.
> ECN marking a packet has the same effect for the sender : reducing cwnd
> exactly like a packet drop. Only difference is avoiding the
That's true for the first mark; any subsequent mark (during the same window)
should have no effect - thus a high marking rate (marking fraction per
window) should not be that much worse... Of course, the queue can never know
the effective window of the tcp stream it is marking...
As a test, when the marking is done really instead of drop, do you see
fairness betwenn the ecn and legacy tcp flows? (if not, the ecn
implementation may be faulty).
> It cannot be used only to send a 'small' warning, while other competing
> non ECN flows have no signal.
> As far as packet schedulers are concerned, there should be no difference
> in ECN marking and dropping a packet. I believe linux packet schedulers
> are fine in this area.
> Now, there are fundamental issues with ECN itself, out of Codel scope,
> thats for sure.
> How widely has been RFC 3540 deployed, anybody knows ?
Virtually not; even if the end hosts negotiate ECN, the network doesn't do
any marking (rendering ecn mood).
Bauer and Beverly, "Measuring the current state of ECN support in server,
clients, and routers",
> Codel mailing list
> Codel at lists.bufferbloat.net
More information about the Codel