All of lore.kernel.org
 help / color / mirror / Atom feed
From: Radoslav Kolev <radoslav_kolev@smartcom.bg>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] squid marking packets
Date: Tue, 23 Jul 2002 09:49:30 +0000	[thread overview]
Message-ID: <marc-lartc-102741777025465@msgid-missing> (raw)
In-Reply-To: <marc-lartc-102733059110532@msgid-missing>

>
>
>---
>Ok, I wasn't entirely sure what you meant - let me summarize and correct
>any mistakes I have made?
>
>1)	You use Squid for web traffic. (Is that all web traffic via
>transparent proxy, or do some clients not use the Squid cache for web?)
>2)	You have other traffic as well such as p2p, ftp, cs etc.
>3) 	You wish to rate-limit any web traffic traffic that isn't
>already in squid's cache.
>4)	You wish to rate-limit all other traffic that's not web also.
>
>If that is the case, then I would make your traffic classifiers handle
>all traffic, except for web traffic, and then use squid's delay pools to
>accommodate and differentiate between cached and non-cached content.
>
>
>Chris
>
>
>
Hi, Chris!
You are perfectly right! I use transperant proxy f?r the web traffic. 
The above lines describe it really well.
The problem with your suggestion is that there's no connection between 
squid and the for example HTB shaper for the other traffic.

I want Client X to have 64kbit guranteed bandwidth, and to be able to 
borrow up to 128kbit if available. My idea was to
make the HTB shaper not account packets belonging to connections of 
squid serving cached pages. I'm not sure, but it seems to me
that the easiest way to accomplish this is to make squid mark these 
packets and let them through at full speed (HTB 1:0 class). All
other traffic is classifies and shaped.

Thats how i understand your suggestion: make a class for Client X rate 
64kbit ceil 128kbit. Then I
don't shape packets coming from the proxy machine. But to what values 
should I limit the bandwidth at squid delay pools?
How would squid know that the user is already using his bandwidth 
playing CS, or doing
someting else squid isn't aware of. And vice versa HTB won't know how 
much bandwidth the user is consuming
through squid browsing the web. These problems would be solved if 
bandwidth is controlled using only one mechanism HTB or delay pools.
Since delay pools are limited to only http and possibli ftp, i think 
using HTB for both is a better choice. Thus I need a way to tell which 
packets
belong to connections served from the cache.

Rado


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

      parent reply	other threads:[~2002-07-23  9:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-22  9:36 [LARTC] squid marking packets Radoslav Kolev
2002-07-23  1:07 ` Chris Harrison
2002-07-23  9:49 ` Radoslav Kolev [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-102741777025465@msgid-missing \
    --to=radoslav_kolev@smartcom.bg \
    --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.