Dropped connect requests & ICMP source quench.

[Victor Lipin]

We have two problems with network performance (HP-UX 11) on D390 2CPU copropate mail (SMTP / POP / IMAP / LDAP / OpenMail for ~2000 users) server:

1. "netstat -s" say, about 4-6% TCP connection requests dropped due to full queue (now dropped ~150k requests).
Setting tcp_conn_request_max=2048 (from default 20) doesn't resolve this problem. In our custom designed mail service queue in listen(2) set to 100.
2. Pinging this host sometimes return "source quench received" diagnostic.
Now this disabled by ip_send_source_quench = 0, but i believe this wrong way.

What's needed to solving this problems?

PS: This box isn't heavily load (memory, cpus, disks usage is intermediate)
PPS: DCE/9000 not installed.

[Alex Glennie]

I beleive your second problem will be fixed under hp-ux 11.01 and will be to
increase the buffer size to 128 K and shorten the wait interval from 5
minutes to 2 minutes, thereby flushing the queue of these unwanted
messages before the queue becomes filled.

Why is it safe to ignore these messages or to turn them off?

A good disscussion of this is in TCPIP Illustrated Volume 1,
by Richard Stevens, pages 160-162.

Here is an excerpt from page 161:

Although RFC 1009 [Braden and Postal 1987] requires a
router to generate source quenches when it runs out of
buffers, the new router requirements RFC [Almquist 1993]
changes this and says that a router must not originate
source quench errors. The current feeling is to deprecate
the source quench error, since it consumes network bandwidth
and is an ineffective and unfair fix for congestion.

Exactly how do I disable source quench?

You can disable source quench in HP-UX 11.0 by executing this command:

ndd -set /dev/ip ip_send_source_quench 0

To disable Source Quench so that it can survive a reboot,
modify the /etc/rc.config.d/nddconf file as follows :

TRANSPORT_NAME[X]=ip
NDD_NAME[X]=ip_send_source_quench
NDD_VALUE[X]=0

Where X is the next logical numerical sequence in a table
of values, with X starting at 0.

I'm unsure about your other question 1) ...anyone .... ?

[Victor Lipin]

Alex, thank you for detailed explanation on second question, but all described actions with "ndd", "nddconf", "ndd -c" already done.
This problem described mainly for exact representation of situation.

Sorry for my poor english, but I'm not understand your "I'm unsure about your other question 1) ...anyone .... ?" I'm mistaked in my phrase?
Well, now:
# netstat -s
tcp:
.....
2228344 connections estabilished (including accepts)
.....
197620 connect request dropped due to full queue
.....

[Vladislav Demidov]

There is HP exlanation of the icmp source quench message:
"The nature of using raw IP sockets is that ALL packets received that match the protocol type of the raw socket are delivered to ALL the sockets using that protocol. It is up to the application to read all the data in it's socket buffer and discard the data it's not interested in. If any of these sockets are full, the icmp source quench message will be generated."

What socket type do you use in your application?
Did you try to increase buffer of your socket?

[Victor Lipin]

No, SOCK_RAW type doesn't used, only SOCK_STREAM in most daemons (smtp/pop3/imap/openmail) and SOCK_DGRAM (in bind). Maybe SOCK_RAW used in system RPC daemon, but this daemon configuration updated (checking period from 30sec to 10sec) as desribed in DCE/9000 patch (sorry, don't remember patch id, but in knowledge base it can be found by "source quench" query).

[新川秀一]

Hi!

ping(1M) is using SOCK_RAW, so RPC daemon(rpcd/dced) sometimes generates the ICMP souce quench.

By the way, DCE/9000 patch is PHSS_20444.