



IntroductionPacket fragmentation occurs when a packet too large for the subsequent link reaches a network interface and is broken up into a series of fragments the size of the MTU of the ensuing link. Packet fragmentation has a negative impact on network performance for several reasons. First, a router has to perform the fragmentation - an expensive operation. Second, all the routers in the path between the router performing the fragmentation and the destination have to carry additional packets with the requisite additional headers. |
|
Glossary![]()
|
|
About This TraceThe data in the following section comes from a trace which contained only fragmented traffic. The trace was taken on the UCSD-CERF link from Wed May 17 14:40:39 PDT 2000 to Fri Jun 2 20:42:48 PDT 2000. 50,375,114 packets containing 50,945,519,628 bytes of data composing 17,718,285 fragment series were captured in this interval. The graphs shown here represent complete fragment series -- series in which all of the fragments were observed. |
|
Fragments Per Fragment SeriesThis graph displays the number of fragments per series. A high number of two and three fragment series is expected for packets whose MTU is a bit too large for the following link. Of note in this graph is the prevalence of series with a large number of fragments, and the prevalence of 21-fragment series preceding a sharp falloff of the number of fragments in higher-fragment-value series. | ![]() |
Bytes Per SeriesThis graph shows the prevalence of the various sizes, in bytes, of fragment series. | ![]() |
First Fragment SizesThis graph shows the prevalence of various sizes into which packets are fragmented. 1484 bytes and 1500 bytes are roughly ethernet maximum packet sizes, so they are expected to be the size into which most packets are fragmented. 1492 byte fragments result from ethernet networks that are using LLC/SNAP in accordance with RFC 1042. 572 is a common PPP MTU, and seems to be a common MTU for many hosts. However the prevalence of 44 byte packets indicate something badly misconfigured, as those packets contain only 4 bytes of payload along with their 40 byte headers. The background level of around 10 series that spans the entire range of shows that there are a significant number of hosts and/or routers configured to fragment traffic to seemingly random MTUs. | ![]() |
Last Fragment SizesThe last fragment sizes have a significant random component, since the size of the last fragment depends on the size of the original packet and on the size of fragments into which the original packet was fragmented - and hosts have a wide range of MTUs, and applications generate a wide range of packet sizes. Two of the peaks (56 and 40 bytes) represent the last fragments of IP/IP (protocol 4) tunneled traffic. | ![]() |
Complete Packet Transmission TimeThis graph shows the number of milliseconds required for complete packet transmission -- the time between the monitoring of the first packet in the series and the monitoring of the last packet in the series. Further analysis has shown that the number of milliseconds for complete fragment series transmission is largely independent of the number of fragments in the series. This transmission time may be indicative of the line rate of the slowest router to handle the packet series after it is fragmented, the speed of the slowest link through which the packet series traveled, or the time difference between different paths taken by various fragments within a series. | ![]() |
Causes of FragmentationA significant portion of the fragmented traffic that crosses the UCSD-CERF link is tunneled traffic. The tunneled traffic consists almost exclusively of 1540 byte packets that are fragmented because of the addition of the 40 byte additional IP header for IP/IP tunneling. Each packet that is fragmented generates roughly twice as much traffic as is necessary to convey its payload to its destination. If the machines originating this tunneled traffic had MTUs set 40 bytes lower in anticipation of the additional 40 byte TCP and IP headers, the load (both the expensive operation of performing the fragmentation and the handling of additional packets) on routers handling this traffic would decrease. |
|
About This TraceThe data in the following section comes from a trace which contained only fragmented traffic and was taken on the UCSD-CERF link from Fri Apr 7 10:38:07 PDT 2000 to Fri Apr 7 14:38:00 PDT 2000. 75,033 packets were captured in this interval. |
|
Tunneled traffic consists only of series lengths of one and two fragments, since the traffic is fragmented as a result of the extra header. | ![]() |
![]() |
|
All tunneled traffic seen on the UCSD-CERF link in this trace had a first fragment that was either 1500 or 1484 bytes. | ![]() |
Most tunneled traffic seen on the UCSD-CERF link in this trace had a last fragment size of either 40 or 56 bytes. There are some last fragments smaller than 40 bytes, since tunneling causes fragmentation of packets in the range (MTU,MTU-40) to be fragmented. | ![]() |
With the exception of the absence of the small spike at just over 1 millisecond, tunneled traffic exhibits the same distribution of times necessary for complete transmission of the fragment series as all other fragmented traffic. | ![]() |
Tunneled Traffic | ![]() |
Non-tunneled Traffic | ![]() |
Remember, Only You Can Prevent Unnecessary Fragmentation! |