From: dancer@zeor.simegen.com dancer@zeor.simegen.com
To: lartc@vger.kernel.org
Subject: [LARTC] Queueing and BGP
Date: Thu, 02 Nov 2000 09:34:45 +0000 [thread overview]
Message-ID: <marc-lartc-98373938216884@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938216879@msgid-missing>
<PRE>Arthur van Leeuwen wrote:
><i> On Wed, 1 Nov 2000, bert hubert wrote:
</I>><i>
</I>><i> > On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote:
</I>><i> >
</I>><i> > > So, It doesn't make sense to mark packet (C) because it will never go to
</I>><i> > > the local network and I cannot control that bandwidth, because I just
</I>><i> > > receive it. And also It doesn't make sense to mark packet (D) because
</I>><i> > > SQUID will eat all the bandwidth with packets (B) and (C) anyway.
</I>><i> >
</I>><i> > Because squids repackets your data, any shaping information is lost. Once
</I>><i> > your data has left squid, there is no way to know anymore where it came
</I>><i> > from.
</I>><i>
</I>><i> > You can try to get the ingress policer working, which tries to do shaping on
</I>><i> > the receiving interface (before squid). This should work, except that people
</I>><i> > have been having trouble with the ingress policer.
</I>><i>
</I>><i> Or, alternately, you might try to configure one squid per bandwith-partition,
</I>><i> thereby getting back your shaping information. This does come at a cost, but
</I>><i> it is actually relatively easy to set up. You might need NAT to do it
</I>><i> though... ;)
</I>><i>
</I>
Hrm. Throttling it on transmission on the internal network interface works for
me....squid doesn't get too far out of control because it won't read too far ahead
of the client. Unfortunately throttling at that point means that cache-hits get
throttled, since I can't think of a good way to deal with this (I'm marking and
queuing on egress into two bandwidth partitions [fast and slow]). Proxy/web
traffic falls into the 'slow' category...and like I said...squid only reads ahead
so far, thus winding up in synch with the client-read speed for any large
objects...it's the cache hits that bite....From the end-user perspective, a hit
looks like a miss...Ie: Same delivery rate.
D
</PRE>
prev parent reply other threads:[~2000-11-02 9:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-01 12:57 [LARTC] Queueing and BGP Gregory
2000-11-01 16:24 ` Aldrin
2000-11-01 17:28 ` bert
2000-11-02 8:20 ` Arthur
2000-11-02 9:34 ` dancer [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-98373938216884@msgid-missing \
--to=dancer@zeor.simegen.com \
--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.