From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>,
bloat <bloat@lists.bufferbloat.net>,
Cake List <cake@lists.bufferbloat.net>
Subject: [Cake] ecn redux
Date: Mon, 13 Aug 2018 15:29:22 -0700 [thread overview]
Message-ID: <CAA93jw5xH1PbwMY0Umtb--hKHibLaWvX4oEfHzDRzOXjsu9g4g@mail.gmail.com> (raw)
In-Reply-To: <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com>
On Tue, Jun 5, 2018 at 12:31 PM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> > On 5 Jun, 2018, at 9:34 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> >
> > The rationale for that decision still is valid, at low bandwidth every opportunity to send a packet matters…
>
> Yes, which is why the DRR++ algorithm is used to carefully choose which flow to send a packet from.
>
> > …and every packet being transferred will increase the queued packets delay by its serialization delay.
>
> This is trivially true, but has no effect whatsoever on inter-flow induced latency, only intra-flow delay, which is already managed adequately well by an ECN-aware sender.
>
> May I remind you that Cake never drops the last packet in a flow subqueue due to AQM action, but may still apply an ECN mark to it. That's because dropping a tail packet carries a risk of incurring an RTO before retransmission occurs, rather than "only" an RTT delay. Both RTO and RTT are always greater than the serialisation delay of a single packet.
>
> Which is why ECN remains valuable even on very low-bandwidth links.
I guess everybody knows at this point that I'm not a big fan of ecn.
I'd done a bit of work on making
"drop and mark" work in earlier versions of cake and completely missed
that it had got ripped out until a month or two back.
I'd like to point at this bit of codel, where it can, does, and will
do bulk dropping, and increase the drop schedule, even drop the last
packet in that queue, while overloaded, in an attempt to get things
back to the real rtt.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/include/net/codel_impl.h#n176
years ago, even on simple traffic, codel would spend 30% of it's time
here. On the kinds of massive overloads
for the path roland has done, it wouldn't surprise me if it was > 90%.
With ecn'd traffic, in this bit of code, we do not drain the excess
packets, nor do we increase the mark rate as frantically. I've aways
felt this was a major flaw in codel's ecn handling, and have tried to
fix it in various ways.
Even pie starts dropping ecn, when the drop probability exceeds 10%.
> - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
parent reply other threads:[~2018-08-13 22:28 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com>]
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw5xH1PbwMY0Umtb--hKHibLaWvX4oEfHzDRzOXjsu9g4g@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=moeller0@gmx.de \
/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