CoDel AQM discussions
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Richard Scheffenegger <rscheff@gmx.at>
Cc: codel@lists.bufferbloat.net, "Bob Briscoe" <bob.briscoe@bt.com>,
	"Dave Täht" <dave.taht@bufferbloat.net>
Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target
Date: Sat, 04 Aug 2012 19:21:22 +0200	[thread overview]
Message-ID: <1344100882.9299.1545.camel@edumazet-glaptop> (raw)
In-Reply-To: <B23F9BBA90ED4456A8689ECB0B0A7B67@srichardlxp2>

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.




      reply	other threads:[~2012-08-04 17:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-04  2:44 Dave Täht
2012-08-04  6:45 ` Eric Dumazet
2012-08-04 21:53   ` Kathleen Nichols
2012-08-05  3:06     ` Andrew McGregor
2012-08-05  5:30       ` Eric Dumazet
2012-08-05 16:53         ` Andrew McGregor
2012-08-05 16:58           ` Kathleen Nichols
2012-08-05 17:14             ` Andrew McGregor
2012-08-05 17:15           ` Eric Dumazet
2012-08-05 16:54         ` Richard Scheffenegger
2012-08-05 17:25           ` Eric Dumazet
2012-08-05 17:35             ` Eric Dumazet
2012-08-05 18:14               ` Yuchung Cheng
2012-08-05 18:40                 ` Eric Dumazet
2012-08-05 19:49                   ` Eric Dumazet
2012-08-06 16:22                   ` Richard Scheffenegger
2012-08-06 16:46                     ` Eric Dumazet
2012-08-06 17:50                       ` Dave Taht
2012-08-06 19:09                         ` Andrew McGregor
2012-08-06 20:01                           ` Eric Dumazet
2012-08-10 17:48                             ` Dave Taht
2012-08-04  7:00 ` Roger Jørgensen
2012-08-04 13:38   ` Richard Scheffenegger
2012-08-04 17:21     ` Eric Dumazet [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1344100882.9299.1545.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=bob.briscoe@bt.com \
    --cc=codel@lists.bufferbloat.net \
    --cc=dave.taht@bufferbloat.net \
    --cc=rscheff@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox