From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Dave Taht <dave@taht.net>,
tsvwg@ietf.org, g.white@cablelabs.com,
bloat@lists.bufferbloat.net
Subject: Re: [Bloat] quick review and rant of "Identifying and Handling Non Queue Building Flows in a Bottleneck Link"
Date: Mon, 29 Oct 2018 15:15:13 +0100 [thread overview]
Message-ID: <877ei096vi.fsf@toke.dk> (raw)
In-Reply-To: <878t2h1jtm.fsf@taht.net>
Hi Greg
Since Dave's email prompted me to read your draft, I thought I'd chime
in with this comment:
Section 3.2 of the draft reads:
> 3.2. Queuing behavior analysis
>
> Similar to the queue protection function outlined in the previous
> section, it may be feasible to devise a real time flow analyzer for a
> node that would identify flows that are causing queue build up, and
> redirect those flows to the QB queue, leaving the remaining flows in
> the NQB queue.
To me, this sounds exactly like a description of what the sparse flow
optimisation of FQ-CoDel, so I'm puzzled why you don't believe this to
be the case? Sure, FQ-CoDel uses its per-flow queueing system as a
mechanism to achieve this, but if you really can't do per-flow queueing,
it is conceivable that the mechanism could be implemented without it.
The high-level logic is basically (in your terms) "on enqueue, does this
flow already have a packet queued? if yes, it's a QB flow, if no, it's
an NQB flow". It is simple, but quite effective.
I've recently analysed the behaviours that fall out of this simple
mechanism in some detail, which may be relevant to your efforts. See
this publication in IEEE Communication Letters:
https://doi.org/10.1109/LCOMM.2018.2871457
-Toke
next prev parent reply other threads:[~2018-10-29 14:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 4:02 Dave Taht
2018-10-29 14:15 ` Toke Høiland-Jørgensen [this message]
2018-10-31 0:12 ` Greg White
2018-11-01 13:25 ` Toke Høiland-Jørgensen
2018-11-01 19:13 ` Dave Taht
2018-11-06 4:17 ` Greg White
2018-11-12 22:19 ` Dave Taht
2018-11-01 10:39 ` Michael Welzl
2018-11-01 14:20 ` Dave Taht
2018-11-04 18:16 ` [Bloat] [tsvwg] " Michael Welzl
[not found] ` <alpine.DEB.2.02.1811011030500.24927@nftneq.ynat.uz>
2018-11-01 18:15 ` [Bloat] " David Lang
2018-11-01 19:12 ` [Bloat] [tsvwg] " Michael Welzl
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=877ei096vi.fsf@toke.dk \
--to=toke@toke.dk \
--cc=bloat@lists.bufferbloat.net \
--cc=dave@taht.net \
--cc=g.white@cablelabs.com \
--cc=tsvwg@ietf.org \
/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