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