RE: PMTU-D: remember, your load balancer is broken

["Roeland Meyer (E-mail)" <rmeyer () mhsc com>]

> 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
be
> > changed with a registry hack.
>
> Expecting the tens of millions of novice computer users to set
their
> systems for a 1500 byte MTU is irrational.  Those who are
> knowledgeable
> enough to do so are generally reducing it due to "speed up your
modem"
> articles and programs which improve interactive performance at
the
> 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
> 64-1518/1522
> > bytes?  And isn't that the limit on most host IP stacks for
Ethernet
> media?

> There are now several devices on the market that will do
> Jumbo frames on
> GigE.  For instance, the Catalyst 6000 and GSR do:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_
5/cmd_refr/set_po_r.htm#xtocid661812

> 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
Jumbo
> 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.