All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Traffic control, squid and priorities
Date: Wed, 16 Apr 2003 19:20:07 +0000	[thread overview]
Message-ID: <marc-lartc-105052090800558@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105051135520821@msgid-missing>

On Wednesday 16 April 2003 18:41, George Spiliotis wrote:
> Dear list members,
>
> I am certainly sure that this question has already been
> answered somehow, somewhere but unfortunately the internet
> is so big these days I need days to check for the right
> information...
>
> I am the administrator for a large company and I want to
> impose some bandwidth management rules to my internal PC's
> as far as the internet is concerned. My linux box acts as a
> firewall & traffic controller. I am running the latest
> kernel & iproute (with dsmark & htb).
>
> All the internal clients go through a proxy (squid) unning
> on the same machine as the firewall and tc. No
> discrimination so far for my bosses PC's (i.e. they
> use squid as well). Now, what I want is described with the
> following simple rules:
>
> 1. When my boss is using the internet (either directly or
> through the proxy) he should get priority over all other
> internal users. In other words, as long as he has packets
> to send, no one else should be allowed to transmit (or
> receive, if possible).
This is almost impossible.  It's better to say "my boss has a minimum 
bandwidth of 60%.  If he is not using it, the rest can use that bandwidth."  

> 2. The rest of the machines should belong to one of two
> groups borrowing from each other: ones with access to the
> 80% of the bandwidth and the others to the 60% of the
> bandwidth. If both groups send too much data then the
> allocation should be in respect to these percentages.
No problem.

> 3. Lastly the usual LARTC low latency rules should apply
> for all the above.
Easy to do.

> My questions are: can these rules be achieved with linux
> traffic control? Can I have rules for packets going *out*
> of the proxy based on relevant information for packets
> going *in* the proxy? i.e. can I mark a packet and have
> squid preserve the marking for his own generated packets?
> Should I impose the above rules on both interfaces
> (internal-external) for my linux box? Are there any
> examples for configurations like these? Something to be
> used as a starting
It can be done.  But squid can break the setup because you don't know who is 
requesting the page if squid goes out to the internet to fetch the page.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

      parent reply	other threads:[~2003-04-16 19:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-16 16:41 [LARTC] Traffic control, squid and priorities George Spiliotis
2003-04-16 16:52 ` Patrick McHardy
2003-04-16 19:20 ` Stef Coene [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-105052090800558@msgid-missing \
    --to=stef.coene@docum.org \
    --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.