|
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
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 media? > 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: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cmd_r efr/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. 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. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, HCOE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: [email protected]
|