North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IP Fragmentation

  • From: Jim Shankland
  • Date: Wed Aug 20 13:48:53 2008
Leo Bicknell wrote:
In a message written on Wed, Aug 20, 2008 at 09:43:44PM +0530, Glen Kent wrote: 
Do transit routers in the wild actually get to do IP fragmentation
these days? [...]

Yes.

A GigE jumbo frames host (9120) to a standard POS interface (4420)
to a DS3 customer (1500) happens, and the GigE->POS and POS->DS3
routers must both do fragmentation.


From the application (as opposed to network operator) point of view,
the big problem with fragmentation is that if you lose one fragment
in transit, all the fragments eventually get discarded, even if they've
made it all the way to the destination.  This hurts performance and
wastes resources.  So you may be better off not sending those jumbo
frames in the first place.

If your packet loss rate, end-to-end, is epsilon, and epsilon is so
small that even several times epsilon is negligible, then maybe you
don't care.  But you're clearly now relying on a higher standard of
performance from the network fabric than you otherwise would be.

Way back when, before my beard was gray, Sun came out with the Sun-4
servers, based on the new SPARC architecture.  These were then widely
deployed as NFS servers for Sun-3 desktops.  The default NFS blocksize
was 8K, the default (maybe only) transport was UDP.  Sun-3 would make
a read request, Sun-4 would send an 8K+ UDP response, which would
get fragmented into a burst of 6 IP fragments, Sun-3 would get
the first 3 or 4 before falling behind (this was, after all, the
blistering fast 10 megabit Ethernet) and dropping a fragment.
Eventually, the reassembly would time out, all the received fragments
would get discarded, NFS would resend ... lather, rinse, repeat.
Setting the NFS read and write sizes to 1460 fixed this by avoiding
fragmentation.

This concludes today's presentation from the history channel.

Jim Shankland