From: Martin Devera <devik@cdi.cz>
To: lartc@vger.kernel.org
Subject: Re: Subject: Re: [LARTC] SFQ + RED
Date: Fri, 07 Dec 2001 22:28:50 +0000 [thread overview]
Message-ID: <marc-lartc-100776423017336@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100774775817462@msgid-missing>
yes I do. I oversight the sfq_drop call in enqueue ;-)
devik
On Fri, 7 Dec 2001, Don Cohen wrote:
>
> After an off-list discussion I think Martin now agrees with me that
> sfq will not let one large flow deny service to all others.
> It's actually the other way around, ensuring service to the small ones
> even at the expense of the large ones.
>
> > From: Martin Devera <devik@cdi.cz>
> >
> > IMHO the RED would be useful here. SFQ limits total packet count
> > to 128 packets. So that one flow can simply fill whole SFQ leaving
> > small space for other flows.
> > I'm able to simulate it using one host generating huge UDP flow.
> > All others flow goes away :(
> >
> > devik
> >
> > On Mon, 3 Dec 2001, Don Cohen wrote:
> >
> > >
> > > > On Tue, Nov 27, 2001 at 11:53:10AM -0500, Michael T. Babcock wrote:
> > > > > I've asked this before, but does anyone feel technically inclined
> > > > > enough to try swapping in a RED queue for the per-bucket queuing done
> > > > > by SFQ? If SFQ builds a series of 'sessions' to be given fair use of
> > > > > available bandwidth, using RED to slow down those that are building up
> > > > > too fast would smooth things out.
> > >
> > > I don't think this is necessary. As it is now, when you enqueue a
> > > packet in a full SFQ queue it drops from the tail of the longest
> > > subqueue. If you have substantial competition for the link then
> > > your subqueue won't be allowed to grow very long to begin with.
> > > The random variation in demand from other flows will have the effect
> > > of jittering the maximum length of your subqueue, which is pretty
> > > similar to what you experience with RED, isn't it?
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
>
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
prev parent reply other threads:[~2001-12-07 22:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-07 17:54 Subject: Re: [LARTC] SFQ + RED Don Cohen
2001-12-07 22:28 ` Martin Devera [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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-100776423017336@msgid-missing \
--to=devik@cdi.cz \
--cc=lartc@vger.kernel.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