Ats.: [squid-users] Re: Squid floods and kills router

Hi,

> There is an open bug report about issues with delay pools, claiming
> that delay pools is not working at all in 2.5.STABLE3 IIRC. I have

I've looked for it in squid-cache.org Bugzilla database, but unable
to find anything related to IRC and delay pools.

Closest match I think is, but nothing like my case:
http://www.squid-cache.org/bugs/show_bug.cgi?id=670

> not yet had time to evaluate this report. Please check if this is
> consistent with what you are seeing on SquidNT, if not open a new
> report.

I'll do it, if you kindly explain my thoughs in the end of the letter.

> As your router is broken and crashes on this kind of traffic, please
> conduct testing of the delay pools feature from another equipment not
> using that router.

I've tested delay pools on direct connection SquidServer<>Client
(only fast swicth between, no router) - client is able to get page,
but trafic is the same - very high number of 1 byte packets.

Client machine - P4 @ 2.4 Ghz, 512 RAM, 100 Mbps 3COM NIC.
Server - much the same HW.

Result - CPU usage when using delay pools peaks from 30% to average 80-90%.
rate measured with snifer - ~20000 packets/sec. In such case I do not wonder
why my small router is out of CPU power to survive!

> Trust me, the router bug should be fixed. Not fixing the router issue
> is asking for trouble later.

I understand that clearly. The problem is that fixing the router this time
is the harder way to go, because it is a part of infrastructure, while Squid
as of today - is not.

> This is kind of the same question if a NT server should bluescreen if
> it receives a certain malformed packet from the network. Sure, in a
> perfect world it should not receive such packets in the first place,
> but it sure should not bluescreen if it does..

Agree again. But while network is under my supervision it is a little perfect
world, where no one knows, what DoS is :) Until Squid ofcourse was installed :)

------------------------------------------

Ok, here is my letter, I have written to Serassio Guido, developer and supervisor
of SquidNT project (all quited text):

> Ok, I am not Squid or delay-pools expert, but what I see with
>snifer, seems to me strange behavior of Squid:
>
>1. On request of web page, which is belongs to delay pool, a client computer
>in the beginning gets only a few quite big packets - from ~100 to ~1500 bytes
>each.
>
>2. This lasts presumably until client computer depletes his initial pool.
>
>3. After this the stream of 1 byte packets is send, making it atleast ~1000-5000
>packets/second, (depending on delay pool restore speed? I think).
>- this is delay pool throtling in use.
>
>4. After page load is almost finished and there is no constant demand
>of download, Squid behavior of packets restores to the one mentioned in 1
>step.
>
> What I do not understand from software design point of view what is
>the difference between 5000 packets/sec with only 1 byte of meaningful payload
>and 5/sec packets with 1000 bytes worth of data each? The difference for the
>end-user or client is the same.
>
> Is this usual/default Squid behavior? Can anything be done to make
>it send
>fewer, but larger packets when using delay pools?
>
> Should I post this question also to the squid-users mailing list?

        So, now I wonder, if:

1. My case is usual Squid behaivior.
        A. If so - can it be changed to send larger, but fewer delayed packets?

2. It is mis-configuration in my config?

3. Squid NT port is broken / mis-implemented in some way.

Thank you again for support!
Received on Sun Jun 22 2003 - 11:40:49 MDT