From: Dave Taht <dave.taht@gmail.com>
To: Benjamin Cronce <bcronce@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] No backpressure "shaper"+AQM
Date: Tue, 24 Jul 2018 13:57:31 -0700 [thread overview]
Message-ID: <CAA93jw7hd13TfXa_ePmp24qG-bzsLBciVpEkhDoC8yf3CFCAzQ@mail.gmail.com> (raw)
In-Reply-To: <CAJ_ENFG7X9Rpxvg6nxEoZ3+hD1tcNx0FAL3C9T40F=zEeEf-DQ@mail.gmail.com>
On Tue, Jul 24, 2018 at 1:11 PM Benjamin Cronce <bcronce@gmail.com> wrote:
>
> Maybe the Bobbie idea already would do this, but I did not see it explicitly mentioned on its wiki.
you are basically correct below. bobbie's core idea was a kinder,
gentler, deficit mode policer, with something fq_codel-like aimed at
reducing accumulated bytes to below the set rate.
this is way different from conventional policers
> The below is all about shaping ingress, not egress.
>
> My issue is that my ISP already does a good job with their AQM but nothing is perfect and their implementation of rate limiting has a kind of burst at the start. According to speedtests, my 250Mb connection starts off around 500Mb/s and slowly drops over the next few seconds until a near perfect 250Mb/s steady state.
ideally their htb shaper would use fq_codel as the underlying qdisc.
Or at least reduce their burst size to something saner. I hope it's
not a policer.
You can usually "see" a policer in action. Long strings of packets are
dropped in a row.
> The burst at the beginning adds a certain amount of destabilization to the TCP flows since the window quickly grows to 500Mb and then has to backdown by dropping. If I add my own traffic shaping and AQM, I can reduce the reported TCP retransmissions from ~3% to ~0.1%.
sure.
>
> The problem that I'm getting is by adding my own shaping, a measurable amount of the benefit of their AQM is lost. While I am limited to Codel, HFSC+Codel, or FairQ+Codel for now, I am actually doing a worse job of anti-bufferbloat than my ISP is. Fewer latency spices according to DSLReports.
? measured how.
>
> This also does not touch on that the act of adding back-pressure in its nature increases latency. I cannot say if it's a fundamental requirement in order to better my current situation, but I am curious if there's a better way. A thought that came to me is that like Bobbie, do a light touch as the packets have already made their way and you don't want to aggressively drop packets, but at the same time, I want the packets that already made the journey to mostly unhindered enter my network.
>
> That's when I thought of a backpressure-less AQM.
I like the restating of what policers do....
>Instead of having backpressure and measuring sojourn time as a function of how long it takes packets to get scheduled, predict an estimated sojourn time based on the observed rate of flow, but allow packets to immediately vacate the queue. The AQM would either mark ECN or drop the packet, but never delay the packet.
aqms don't delay packets. shapers do.
> In summary, my ISP seems to have better latency with their AQM, but due to their shaper, loss during the burst is much higher than desirable.
>
> Maybe this will be mostly moot once I get fq_codel going on pfSense, but I do find it an interesting issue.
I thought it's been in there for a while?
> _______________________________________________
> 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
next prev parent reply other threads:[~2018-07-24 20:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-24 20:11 Benjamin Cronce
2018-07-24 20:33 ` Jonathan Morton
2018-07-24 20:48 ` Benjamin Cronce
2018-07-24 20:57 ` Dave Taht [this message]
2018-07-24 21:31 ` Dave Taht
2018-07-26 4:42 ` Dave Taht
2018-07-24 21:39 ` Benjamin Cronce
2018-07-24 21:44 ` Jonathan Morton
2018-07-24 21:58 ` Dave Taht
2018-07-24 22:12 ` Dave Taht
2018-07-25 0:11 ` Benjamin Cronce
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw7hd13TfXa_ePmp24qG-bzsLBciVpEkhDoC8yf3CFCAzQ@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bcronce@gmail.com \
--cc=bloat@lists.bufferbloat.net \
/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