From: Sebastian Moeller <moeller0@gmx.de>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: cake@lists.bufferbloat.net, Daniel Havey <dhavey@gmail.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Cake] active sensing queue management
Date: Wed, 10 Jun 2015 22:54:18 +0200 [thread overview]
Message-ID: <EF99AA07-D411-48CE-B14F-EE88B95A683A@gmx.de> (raw)
In-Reply-To: <CAA93jw4TSXDEe8Y0VCRQvS5xKU6sM4t5or962iv079-FcCEMNQ@mail.gmail.com>
Hi Dave,
On Jun 10, 2015, at 21:53 , Dave Taht <dave.taht@gmail.com> wrote:
> http://dl.ifip.org/db/conf/networking/networking2015/1570064417.pdf
>
> gargoyle's qos system follows a similar approach, using htb + sfq, and
> a short ttl udp flow.
>
> Doing this sort of measured, then floating the rate control with
> "cake" would be fairly easy (although it tends to be a bit more
> compute intensive not being on a fast path)
>
> What is sort of missing here is trying to figure out which side of the
> bottleneck is the bottleneck (up or down).
Yeah, they relay on having a reliable packet reflector upstream of the “bottleneck” so they get their timestamped probe packets returned. In the paper they used either uplink or downlink traffic so figuring where the bottleneck was easy at least this is how I interpret “Experiments were performed in the upload (data flowing from the users to the CDNs) as well as in the download direction.". At least this is what I get from their short description in glossing over the paper.
Nice paper, but really not a full solution either. Unless the ISPs cooperate in supplying stable reflectors powerful enough to support all downstream customers. But if the ISPs cooperate, I would guess, they could eradicate downstream buffer bloat to begin with. Or the ISPs could have the reflector also add its own UTC time stamp which would allow to dissect the RTT into its constituting one-way delays to detect the currently bloated direction. (Think ICMP type 13/14 message pairs "on steroids", with higher resolution than milliseconds, but for buffer bloat detection ms resolution would probably be sufficient anyways). Currently, I hear that ISP equipment will not treat ICMP requests with priority though.
Also I am confused what they actually simulated: “The modems and CMTS were equipped with ASQM, CoDel and PIE,” and “However, the problem pop- ularly called bufferbloat can move about among many queues some of which are resistant to traditional AQM such as Layer 2 MAC protocols used in cable/DSL links. We call this problem bufferbloat displacement.” seem to be slightly at odds. If modems and CTMS have decent AQMs all they need to do is not stuff their sub-IP layer queuesand be done with it. The way I understood the cable labs PIE story, they intended to do exactly that, so at least the “buffer displacement” remedy by ASQM reads a bit like a straw man argument. But as I am a) not of the cs field, and b) only glossed over the paper, most likely I am missing something important that is clearly in the paper...
Best Regards
Sebastian
>
> --
> Dave Täht
> What will it take to vastly improve wifi for everyone?
> https://plus.google.com/u/0/explore/makewififast
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
next prev parent reply other threads:[~2015-06-10 20:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 19:53 [Cerowrt-devel] " Dave Taht
2015-06-10 20:54 ` Sebastian Moeller [this message]
2015-06-11 0:10 ` [Cerowrt-devel] [Cake] " Daniel Havey
2015-06-11 7:27 ` Sebastian Moeller
2015-06-12 15:02 ` Daniel Havey
2015-06-12 16:02 ` Sebastian Moeller
2015-06-12 1:49 ` David Lang
2015-06-12 14:44 ` Daniel Havey
2015-06-13 4:00 ` David Lang
2015-06-13 5:50 ` Benjamin Cronce
2015-06-11 1:05 ` Alan Jenkins
2015-06-11 7:58 ` Sebastian Moeller
2015-06-12 1:44 ` [Cerowrt-devel] [Bloat] " David Lang
2015-06-12 9:52 ` MUSCARIELLO Luca IMT/OLN
2015-06-12 16:51 ` Benjamin Cronce
2015-06-13 4:16 ` David Lang
2015-06-12 12:18 ` Sebastian Moeller
2015-06-12 13:00 ` Alan Jenkins
2015-06-12 14:35 ` Daniel Havey
2015-06-12 17:55 ` Alan Jenkins
2015-06-13 4:34 ` David Lang
2015-06-13 4:30 ` David Lang
2015-06-13 5:37 ` [Cerowrt-devel] [Cake] [Bloat] " 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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EF99AA07-D411-48CE-B14F-EE88B95A683A@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=dhavey@gmail.com \
/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