From: Michael Richardson <mcr@sandelman.ca>
To: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net,
bloat@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available
Date: Tue, 07 May 2013 09:31:05 -0400 [thread overview]
Message-ID: <19404.1367933465@sandelman.ca> (raw)
In-Reply-To: <5181CD56.9050501@superduper.net>
>>>>> "Simon" == Simon Barber <simon@superduper.net> writes:
Simon> Or one could use more queues in SFQ, so that the chance of 2
Simon> streams sharing
Simon> a queue is small. Even perhaps use a different strategy than
Simon> hashing to
Simon> distribute traffic to queues, although whatever strategy is
Simon> used needs to be
Simon> resistant to DoS attacks. Or one could classify the VoIP traffic and
Simon> prioritise that. Another possibility is a heuristic approach
Simon> - don't mix long
Simon> lived bulk data streams in the same bucket as others.
1) try to give each IPv6 non-zero flow label stream to it's own bucket.
(use a closed hashing strategy)
Yes, this leverages an IPv6 feature which should promote v6...
2) otherwise, hash TCP and UDP streams into seperate pools. On simple
networks with no gaming, this results in VoIP RTP flows and DNS
always getting their own stream.
On networks with agressive UDP flows which do not react, one needs
another method to seperate the flows and penalize them individually.
if NAT is involved, then conn-tracking can basically give every flow
it's own queue, because they are already uniquely identified.
I think that the number of queues for TCP streams can be smaller than
for UDP streams, as the TCP streams are more likely to respond to
congestion signals.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
next prev parent reply other threads:[~2013-05-07 13:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-01 11:23 [Cerowrt-devel] " Dave Taht
2013-05-01 20:26 ` [Cerowrt-devel] [Bloat] " Simon Barber
2013-05-02 0:00 ` Jonathan Morton
2013-05-02 2:20 ` Simon Barber
2013-05-02 4:59 ` [Cerowrt-devel] [Codel] " Andrew McGregor
2013-05-02 12:04 ` [Cerowrt-devel] " Jonathan Morton
2013-05-14 2:26 ` [Cerowrt-devel] [Codel] " Dan Siemon
2013-05-14 4:56 ` [Cerowrt-devel] [Bloat] [Codel] " Tristan Seligmann
2013-05-14 10:24 ` Dave Taht
2013-05-14 13:02 ` [Cerowrt-devel] [Codel] [Bloat] " Eric Dumazet
2013-06-11 18:19 ` [Cerowrt-devel] [Bloat] [Codel] " Michael Richardson
2013-05-14 12:12 ` [Cerowrt-devel] [Codel] [Bloat] " Jesper Dangaard Brouer
2013-05-06 17:54 ` Jesper Dangaard Brouer
2013-05-06 18:46 ` Jonathan Morton
2013-05-06 20:47 ` Jesper Dangaard Brouer
2013-05-07 16:22 ` Greg White
2013-05-07 13:31 ` Michael Richardson [this message]
2013-05-07 16:30 ` [Cerowrt-devel] " Greg White
2013-05-07 19:56 ` Wes Felter
2013-05-07 20:30 ` Eric Dumazet
2013-05-08 22:25 ` Dave Taht
2013-05-08 22:54 ` Eric Dumazet
2013-05-09 1:45 ` [Cerowrt-devel] [Codel] " Andrew McGregor
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=19404.1367933465@sandelman.ca \
--to=mcr@sandelman.ca \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--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