In association with heise online

Thrifty bytes

One TCP parameter people love to play with is the MTU, the maximum transmission unit. MTU defines the maximum packet size which can be forwarded by the network without being fragmented. Competing factors influence the optimum size.

The larger the MTU, the better the ratio of TCP/IP header data to payload data. A TCP/IP header consists of 40 bytes. Switching from a smaller (e.g. 576 bytes) to a larger MTU of 1500 bytes reduces the proportion made up by the header from 6.9 to 2.7 per cent.

image 5 [250 x 175 Pixel @ 24,5 KB]
Zoom Traffic shapers such as NetLimiter limit the upload speed of programs of the user's choice, thereby ensuring that they cooperate rather than compete in utilising the internet connection.
However, it is also the case that the larger the packet, the more time is required for it to be transmitted. Where interactive applications, such as an ssh session or a VoIP telephone call, are running at the same time as an upload, it may occur that an ssh packet forwarding a single input character ends up lined up behind a 1500 byte upload packet, so that it can only be sent after that packet has cleared. With an upstream speed of 192kbit/s (24kB/s), this takes 62ms. This is enough to be a potential problem for interactive applications such as ssh sessions or telephone calls. A smaller packet of 576 bytes clears the buffers in just 24ms, meaning that mixed traffic flows more freely. This can be advantageous for applications such as online gaming.

Increasing upstream bandwidths are increasingly mitigating this problem. MTUs larger than 1500 bytes are atypical and not really achievable, as the Ethernet connections used by many providers to forward packets internally transport a maximum of 1500 bytes per packet. In addition, PPPoE packets have a maximum size of 1492 bytes, so that a DSL router would have to divide a 1500 byte Ethernet packet from the LAN into two PPPoE packets anyway. This will significantly reduce throughput. One would contain the maximum 1492 bytes of IP data plus eight bytes of PPPoE header, the second just the remaining eight bytes of the Ethernet frame as payload data, plus the 20 byte IP header and 8 byte PPPoE header.

Auto-MTU

Happily, the sender can work out the optimum MTU value as long as path MTU discovery is enabled. It then reduces this value automatically, since TCP does everything it can to prevent packets from being fragmented; it takes time and memory to reassemble fragmented packets. Larger packets are also more expensive when packets are lost - it takes longer for the error to be corrected and the reduction in throughput is greater than with a smaller MTU.

With path MTU discovery, all packets are labelled with the "Don't Fragment" bit and initially sent with the maximum size for the network adapter. If one of the routers on the route is unable to forward the packet without fragmenting it (which it is forbidden from doing by the Don't Fragment bit), it discards the packet and sends the sender an error message which includes its maximum packet size.

The sender then adjusts the packet size and repeats the process until its packets are able to reach their destination. Because the route between the sender and recipient can change, the sender will occasionally repeat this process. On DSL with PPPoE the MTU is 1492 bytes, on ISDN, DSL with PPPoA or cable it is usually 1500 bytes.

When a TCP connection is established, both parties send the maximum segment size which they are able to accept. This value is equal to the MTU, minus 40 bytes for the TCP/IP header. Thus if one terminal reports MSS = 1460, it can use packets of up to 1500 bytes (1460 + 40). The MSS is, however, simply an upper limit. If path MTU discovery determines a smaller value, this latter will be used.

Print Version | Permalink: http://h-online.com/-747378
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit