On Wed, 17 Nov 2004 10:01:00 -0500, Bruce Collins <[log in to unmask]>
wrote:

>We have web site which is sending XML requests to an application listening
on a socket on the HP3000. It has been working fine for several clients,
but we recently installed it at a new client in France and it has being
acting up.
>
>Most requests are being received properly but we've found that whenever
the request exceeds 1450 bytes the socket server is logging the socket
connection, but it isn't receiving the data. The same requests works
properly when sent to our HP here in Montreal, so I'm assuming it has
something to do with the network configuration of the HP in France.
>
>In NETTOOLS I have seen occasions where the Inbound Buffer Pool has been
filled, but this doesn't seem to be the problem in this particular case.
The Inbound Buffer Pool is still happy :) after the large transaction, and
subsequent smaller requests continue to work properly.
>
>Does anybody have any ideas as to what I should be checking?
>
>Also, I would like to increase the configured size of the Inbound Buffer
Pool but I can't for the life of me remember how to do that.
>
>---------------------------------------------------------------------------
--------
>Bruce Collins                        <[log in to unmask]>
>Technical Specialist             Phone : (514) 273-0008
>Lee Merrick & Assoc.          Fax      : (514) 273-0199
>---------------------------------------------------------------------------
--------
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

Check MTU (Maximum Transmission Unit) on firewall and router(s)- .

See http://www.psc.edu/~mathis/MTU/ for more info/background ... here is a
sample excerpt.

The problems with path MTU discovery are well documented in RFC2923 by
Kevin Lahey. Since these problems generally cause hard-to-diagnose
connection (and application) hangs, nearly all operating systems are
shipped with path MTU discovery effectively disabled and a 1500 byte
default MTU. This has many very serious opportunity costs: starting with
great difficulty deploying all tunneling protocols at all layers: PPPOE,
VPNs, IPsec, and various IPv6 migration and mobility strategies. The
problem is so severe that there is significant resistance in the IETF to
tunneling protocols because they result in MTU's that are slightly smaller
than standard Ethernet, leading to either pervasive IP fragmentation or the
risk of connection hangs due to failed path MTU discovery.

Another opportunity cost of disabling MTU discovery is that ordinary users
are completely unaware of how much MTU affects performance, because they
fail to use larger MTUs when they are available. We suspect that this is
the primary reasons that the Internet community considers 1500 bytes
acceptable. If path MTU discovery had been working well in 1990, it would
have been obvious that FDDI (4352 bytes) outperforms 1500 byte Ethernet,
and there would have been 12 years of market pressure to push up the
Internet MTU.

The original IETF Path MTU Discovery (pmtud) working group has been re-
charted. The unofficial WG status page is a good place to start.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *