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.
prev parent 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