From: sahil grover <sahilgrover013@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] SfqCodel
Date: Sat, 11 Apr 2015 13:41:41 +0530 [thread overview]
Message-ID: <CADnS-2i9NznQ2GLWzn67JFPsJWAOb4iRo+7_0ypJui1KXDcaKA@mail.gmail.com> (raw)
In-Reply-To: <CAJq5cE3oh3BD-X9py_6CD1VAgMC7EUpNmMSk+BqA3-iAUFPsBg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
thanks for your help as always.
On Sat, Apr 11, 2015 at 2:25 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:
> SFQ is quite simple in essence. It performs flow isolation, allowing
> packets from different flows to bypass each other.
>
> A flow is defined as packets possessing a common 5-tuple of source
> address, destination address, protocol (TCP, UDP, ICMP etc), source port
> and destination port.
>
> Ideally, Fair Queuing would perfectly separate all flows into queues, then
> service each of them equally and fairly in turn, for some measure of
> equality and fairness. This would provide ideal flow isolation.
>
> SFQ is not quite this ideal model. The 5-tuple is converted into a hash
> value which is used directly to index into a fixed list of queues; thus
> hash collisions can occur which mix traffic from multiple flows in the same
> queue. It also services queues in a strict round-robin, delivering one
> packet per cycle, regardless of the relative sizes of these packets. These
> are compromises intended to minimise CPU overhead and implementation
> complexity. (They made sense at the time when SFQ was cutting edge, which
> was a long time ago.)
>
> Fq_codel as implemented in Linux is not the same as sfq_codel as
> implemented in ns2. Instead of using SFQ to provide flow isolation, it uses
> DRR++, which provides bytewise fairness and a priority boost to sparse
> flows. Recent work has also found a way to significantly reduce the hash
> collision problem without imposing much additional overhead, and this has
> been incorporated into cake.
>
> - Jonathan Morton
>
[-- Attachment #2: Type: text/html, Size: 2009 bytes --]
prev parent reply other threads:[~2015-04-11 8:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 20:30 sahil grover
2015-04-10 20:55 ` Jonathan Morton
2015-04-11 8:11 ` sahil grover [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=CADnS-2i9NznQ2GLWzn67JFPsJWAOb4iRo+7_0ypJui1KXDcaKA@mail.gmail.com \
--to=sahilgrover013@gmail.com \
--cc=chromatix99@gmail.com \
--cc=codel@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