From: Nuutti Kotivuori <naked@iki.fi>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: ESFQ Modification
Date: Thu, 26 Feb 2004 10:58:27 +0000 [thread overview]
Message-ID: <87ad365cq4.fsf@iki.fi> (raw)
Robert Kurjata wrote:
> Some time ago I faced a problem in limiting traffic on host with
> multiple uplinks. Since all the stuff worked nice seemed that there
> will be no problems. But then I realized that P2P users are smart
> enough to bypass limits as sfq doesn't give fair sharing in this
> case (thousands of connections from one user versus few from the
> other). I tried IMQ but it's instability in my configuration was
> painfull. So I made something like that:
>
> 1. i use IPMARK patch for the iptables to mark all the connections
> in P2P related class depending on source IP (i use SNAT),
> 2. modified ESFQ to create hash depending on FWMARK instead of src
> ip 3. and it worked. So I have uplink policy based on source ip in
> snat-ed environment without using IMQ.
>
> I'm looking for the opinions, cause I may be wrong in this.
> Patch for the files below, cause it's short
Quite an unorthodox solution, I must say. But I guess it's as valid as
anything is. SFQ and ESFQ are usually for situations where you have a
large amount of connections (hashes) that you just cannot track
invidually. Hence stochastic - and hence the options for perturbation
and so. If there's only a few hashes, as most likely is in your NFMARK
case, most of the time they will hit separate hash buckets - but on
some perturbation, they might hit the same hash buckets again and
fairness is not achieved.
The patch as it was by my brief peek, looked rather okay, though.
Have you looked in to the WRR scheduler? It is meant to give an equal
share of bandwidth to all 'local' machines with weighted round robin
scheduling and sounds like exactly what you are looking for.
-- Naked
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
reply other threads:[~2004-02-26 10:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=87ad365cq4.fsf@iki.fi \
--to=naked@iki.fi \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.