[Codel] [PATCH net-next] fq_codel: report congestion notification at enqueue time

Yuchung Cheng ycheng at google.com
Thu Jun 28 18:56:46 EDT 2012

On Thu, Jun 28, 2012 at 11:12 AM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Thu, 2012-06-28 at 10:51 -0700, Dave Taht wrote:
>> clever idea. A problem is there are other forms of network traffic on
>> a link, and this is punishing a single tcp
Dave: it won't just punish a single TCP, all protocols that react to
XMIT_CN will share similar fate.

>> stream that may not be the source of the problem in the first place,
>> and basically putting it into double jeopardy.
> Why ? In fact this patch helps the tcp session being signaled (as it
> will be anyway) at enqueue time, instead of having to react to packet
> losses indications given (after RTT) by receiver.
> Avoiding losses help receiver to consume data without having to buffer
> it into Out Of Order queue.
> So its not jeopardy, but early congestion notification without RTT
> delay.
> NET_XMIT_CN is a soft signal, far more disruptive than a DROP.
I don't read here: you mean far "less" disruptive in terms of performance?

>> I am curious as to how often an enqueue is actually dropping in the
>> codel/fq_codel case, the hope was that there would be plenty of
>> headroom under far more circumstances on this qdisc.
> "tc -s qdisc show dev eth0" can show you all the counts.
> We never drop a packet at enqueue time, unless you hit the emergency
> limit (10240 packets for fq_codel). When you reach this limit, you are
> under trouble.

Another nice feature is to resume TCP xmit operation at when the skb
hits the wire.
My hutch is that Eric is working on this too.

More information about the Codel mailing list