Home page logo

nanog logo nanog mailing list archives

RE: PMTU-D: remember, your load balancer is broken
From: "Roeland Meyer (E-mail)" <rmeyer () mhsc com>
Date: Thu, 15 Jun 2000 09:19:47 -0700

Stephen Sprunk: Wednesday, June 14, 2000 3:48 PM

Sez <rdobbins () netmore net>
The 576 value of the MS PPP MTU is merely a default - it can
changed with a registry hack.

Expecting the tens of millions of novice computer users to set
systems for a 1500 byte MTU is irrational.  Those who are
enough to do so are generally reducing it due to "speed up your
articles and programs which improve interactive performance at
expense of throughput.

How does this effect the link when the server explicitly sets
MTU=512+40, in the server-side of the PPP link? AFAICT, that
over-rides whatever the end-user may want to do.

I thought the frame-size limits for Gigabit Ethernet were
bytes?  And isn't that the limit on most host IP stacks for

There are now several devices on the market that will do
Jumbo frames on
GigE.  For instance, the Catalyst 6000 and GSR do:


I know there are several other vendors who support Jumbo frames
as well.

Finally, I would say that on any medium, <100% utilization in
and of
itself isn't grounds for fiddling with the MTU.  There are
lots of other
things to look at, first.

Without doing performance analysis on the actual running code,
there really isn't a lot else to look at. In my case, we are
looking at the web-server<->RDBMS link, which I've already
architcted to be on a dedicated switch segment. We already know
that we'll never get much less than 3KB data transfers on that
bus and it could get as high as 50KB. Larger transfers will also
happen, occasionally. Where it hits the WAN is the OPS pipe to
the fail-over site. We're looking at that now.

I hear consistent requests from server folks for higher MTUs;
they claim
the per-frame CPU hit is significant enough to warrant using
frames to increase throughput.  The results clearly show that
it helps.

It isn't really the CPU hit, although that may be a factor, we
have intentionally over-built CPU because it's relatively cheap.
The problem is that we aren't getting enough CPU utilization,
because the xfer rates are too slow. That's how we found the
problem in the first place. We've identified the source as being
in the ramping algorithms (which make no sense in a switched
environment, IMHO). A way to get a faster ramp is to have larger
packet sizes to begin with. Since our switch-gear can handle it
(all Cisco) the real issue is how this effects the WAN? There are
also limits to how much we can tinker with the TCP/IP stacks on
the RDBMS machine.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]