North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: rdobbins
  • Date: Wed Jun 14 22:10:50 2000

Nobody expects anyone to change millions of dial-up MTUs; it was just a
response to the original poster's query as to the origin of that figure.

I've been DoSed via fragmentation, so it -can- happen.  Agreed, it's not all
that common.

Thanks much for the info on Cisco 'Giant Frame' support; I know that'll come
in handy!

Server folks will often tell you that they need huge MTUs - and in some
cases, they're correct.  In other cases, it actually ends up hindering
performance, depending upon the application and the entire end-to-end
network topology.

Playing with MTUs is very much like configuring filesystem block-size, or
the application-specific buffering in a big RDBMS like Oracle.  The main
difference is that although one doesn't often see big RDBMS servers used for
other things (allowing the server OS and the applications on it to be
tweaked so as to squeeze out every erg of performance for a single purpose),
networks in general, and carrier networks in particular, are generally used
for all sorts of things.  And besides the potential effect of an altered MTU
size on application performance, one then runs into the question of whether
it's an efficient use of bandwidth overall.

So, I guess it makes sense to have a -thorough- understanding of one's
topology and application characteristics prior to fiddling about with the
MTU size.  I can see that it may well offer the potential of a big win at
the core, but moving towards the edges, I should think the benefits tend to
taper off.  There can't really be a rule of thumb for this sort of thing, of
course; by nature, it's highly situationally dependent.

-----Original Message-----
From: Stephen Sprunk [mailto:[email protected]]
Sent: Wednesday, June 14, 2000 3:48 PM
To: [email protected]
Cc: North American Noise and Off-topic Gripes
Subject: Re: PMTU-D: remember, your load balancer is broken 

Sez <[email protected]>
> 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.

> Forcing excessive fragmentation/defragmentation is an effective DoS.

Effective, but a fairly difficult problem to exploit.

> 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
> Or am I off in left field, here?

IIRC, during development of the GigE spec, several vendors wished to
increase the GigE MTU to ~9000 bytes.  Due to the technical
ramifications of bridging to low-MTU FastE segments, as well as
inter-vendor politics, it didn't make it as part of the GigE spec but
was later published as an optional extension.

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
> isn't grounds for fiddling with the MTU.  There are lots of other
things to
> look at, first.

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.


     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, HCOE
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: [email protected]