Re: What's the best configuration for this setup?

Hi,

Also, if you upgrade the Cisco IOS to 11.1 or higher, Weighted Fair Queuing (WFQ) will help is you have it on both sides of the international link.

Although, WFQ is most effective when your link nears saturation.

Barry

Peter Marelas wrote:

>I dont think it should be the function of the application.
>
>Have a look at your core routers, they should provide you with the ability
>to
>prioritise packets based on the function.
>
>Thus, you wont be limiting the bandwidth used by squid, and you will be
>providing interactive TCP sessions with good responses.
>
>A'la Cisco.
>
>priority-list 1 protocol ip low tcp 8080
>priority-list 1 protocol ip low tcp nntp
>priority-list 1 protocol ip high tcp telnet
>priority-list 1 protocol ip high tcp www
>
>Regards
>Peter Marelas
>
>On Sun, 24 Nov 1996, Dancer wrote:
>
>> Agreed..in principle. However..
>>
>> Here's our situation. As an ISP, we started with a single 14k4 modem (at
>> that time, it cost us many thousands of dollars, and was acceptable, even
>> when shared among a large number of users. Of course, we didn't have the
>> WWW then, either). Then we ramped up to a 64K link, then 128K, now 256K.
>>
>> At the same time 'infrastructure' bandwidth has been on the increase as
>> well. From a measly 2Mbps, now to a lofty 6Mbps across the pacific, and
>as
>> much as 8Mbps between cities.
>>
>> What we're now seeing (esp, with caching proxies, which we use
>> _extensively_), is that each increase in bandwidth makes it more likely
>> that a fast-delivering document (ie: from a fast site, or served from
>the
>> upstream cache on the other side of our link) will flood the link,
>> rendering other connections (non-proxied ftp, telnet, and even other http
>> connections) well..the word 'shitty' comes to mind (It's okay kids, I'm
>an
>> australian, and I used it in a complete sentence).
>>
>> Bearing that in mind, I wouldn't mind seeing a 'virtual partitioning'
>for
>> squid bandwidth:
>>
>> Squid is told something like: 'max_bandwidth 44Kbps' and makes sure that
>it
>> does not read more than 44kilobaud from document-fetches in any second
>> (neighbours don't count towards this number. They're presumably free,
>being
>> on the inside of the link we're trying to protect, we hope). Delivery
>of
>> documents is unaffected (let them get their own limiters, for gosh sakes).
>> Obviously, the specified marker will be exceeded as tcp queues fill up,
>but
>> after that point it should hover roughly around the specified number.
>>
>> Not an ideal solution, but it wouldn't take much fiddling to get a number
>> that serves well-enough. Or you can measure with a cron job...or maybe
>even
>> reconfigure on the fly. Up to you, I guess...but without _something_ of
>> this order, every improvement in 'visible' bandwidth (wether it be actual
>> link widening, improvements in protocols, or caching technologies) actually
>> impacts more and more heavily on the response times for other connections,
>> during the duration of a request.
>>
>> Squid might not be the ideal vehicle to test-drive this sort of thing,
>but
>> it's something to think about. Our current protocol family is doing the
>> best it can, but I don't think it was ever envisioned what sort of weird
>> shit we do with them today. I have high hopes that HTTP/1.1 and IPv6 will
>> help, but I won't bet any body-parts just yet.
>>
>> (Cultural references: Yes, Australians really do swear. A lot. Over the
>> last two-hundred years or so, casual verbal profanity has wormed it's
>way
>> into our culture. I honestly can't think of any words at all that the
>> 'average' australian would find offensive, or even notice in casual
>> conversation. Yes, there are always more extreme people (a bell-curve
>has
>> two ends, naturally) who find relatively inoffensive things shocking.
>I
>> expect everyone knows a few of them. And, yes...Our head of state swore
>at
>> the queen. Quite colourfully, and (I am told) strongly. And it was t could be - any bandwidth determining step would need
>many
>> Kb
>> > before coming even close to an estimate.
>> >
>> > Just my 2p
>> >
>> > Jonathan L.
>> > Origin IT Services Ltd., 323 Cambridge Science Park, Cambridge, England.
>> > Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess...
>> > -------[ Do not think that every sad-eyed woman has loved and lost...
>> ]------
>> > -----------------------[ she may have got him. -Anon
>> ]-----------------------
>> > These opinions are all my own fault.
>>
>>
>
>--
>The Fulcrum Consulting Group Peter Marelas - Consultant
>12/10-16 Queen St, Melbourne VIC 3000,Australia Ph: +61-3-9621-2100
>PGP Key -> finger maral@fusion.mel.sprint.com.au Fx: +61-3-9621-2724
>
>
>

--
Barry Raveendran Greene             |       ||        ||        |
Senior Consulting Engineering       |       ||        ||        |
Singapore                           |      ||||      ||||       |
tel: +65 738-5535 ext 235           |  ..:||||||:..:||||||:..   |
e-mail: bgreene@cisco.com           |  c i s c o S y s t e m s  |