Examine individual changes

'In [[computer networking]], the '''maximum transmission unit (MTU)''' of a [[communications protocol]] of a [[OSI model|layer]] is the size (in [[byte]]s) of the largest [[protocol data unit]] that the layer can pass onwards. MTU parameters usually appear in association with a communications interface ([[network interface card|NIC]], [[serial port]], etc.). Standards ([[Ethernet]], for example) can fix the size of an MTU; or systems (such as point-to-point serial links) may decide MTU at connect time. A larger MTU brings greater efficiency because each packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means a slight improvement in bulk protocol throughput. A larger MTU also means processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation. Large packets can occupy a slow link for some time, causing greater delays to following packets and increasing [[lag]] and minimum latency. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer (and hence over most of the [[Internet]]), ties up a [[14.4k modem]] for about one second. Large packets are also problematic in the presence of communications errors. Corruption of a single bit in a packet requires that the entire packet be retransmitted. At a given [[bit error rate]] larger packets are more likely to be corrupted. Retransmissions of larger packets take longer. ==Table of MTUs of common media== Note: the MTUs in this section are given as the maximum size of IP packet that can be transmitted without fragmentation - including IP headers but excluding headers from lower levels in the protocol stack. The MTU must not be confused with the minimum [[datagram]] size that all hosts must be prepared to accept, which has a value of 576 for IPv4<ref>RFC 791, p. 13</ref> and of 1280 for IPv6.<ref>RFC 2460, p. 13</ref> {| class="wikitable" |- ! Media ! Maximum Transmission Unit (bytes) ! Notes |- | [[Internet]] IPv4 Path MTU | At least 68<ref>RFC 791, p. 24, "Every internet module must be able to forward a datagram of 68 octets without further fragmentation."</ref> | Practical path MTUs are generally higher. IPv4 links must be able to forward packets of size up to 68 bytes. Systems may use [[Path MTU Discovery]]<ref name=rfc1191/> to find the actual path MTU. This should not be mistaken with the packet size every host must be able to handle, which is 576.<ref>RFC 791, p. 24, "Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled."</ref> |- | [[Internet]] IPv6 Path MTU | At least 1280<ref>RFC 2460</ref> | Practical path MTUs are generally higher. Systems must use Path MTU Discovery<ref>RFC 6145</ref> to find the actual path MTU. |- | [[Ethernet II framing|Ethernet v2]] | 1500<ref name=rfc1191>RFC 1191</ref> | rowspan=2 | Nearly all IP over Ethernet implementations use the Ethernet V2 frame format. |- | [[IEEE 802.3|Ethernet (802.3)]] | 1492<ref name=rfc1191/> |- | Ethernet [[Jumbo Frames]] | 1500-9000 | The limit varies by vendor. For correct interoperation, the whole Ethernet network must have the same MTU. Jumbo frames are usually only seen in special purpose networks. |- | [[IEEE 802.11|WLAN (802.11)]] | 2272<ref>[http://www.wireless-center.net/Wireless-Internet-Technologies-and-Applications/1925.html Structure of the IEEE 802.11 MAC Frames - Wireless,Wlan,wifi,Configuration,and,Optimization Tips<!-- Bot generated title -->]</ref> | |- | [[IEEE 802.5|Token Ring (802.5)]] | 4464 | |- | [[FDDI]] | 4352<ref name=rfc1191/> | |} ==IP (Internet protocol)== [[DARPA]] designed the [[Internet protocol suite]] to work over many networking technologies, each of which may have different sized packets. While a host will know the MTU of its own interface and possibly that of its peers (from initial handshakes), it will not initially know the lowest MTU in a chain of links to any other peers. Another potential problem is that higher-level protocols may create packets larger than a particular link supports. To get around this issue, IP allows [[IP fragmentation|fragmentation]]: dividing the [[datagram]] into pieces, each small enough to pass over the single link that is being fragmented for, using the MTU parameter configured for that interface. This fragmentation process takes place at the IP layer ([[Network layer|OSI layer 3]]) and marks packets it fragments as such, so that the IP layer of the destination host knows it should reassemble the [[packet (information technology)|packets]] into the original datagram. This method implies a number of possible drawbacks: * All fragments of a packet must arrive for the packet to be considered received. If the network drops any fragment, the entire packet is lost. * When the size of most or all packets exceed the MTU of a particular link that has to carry those packets, almost everything has to be fragmented. In certain cases the overhead this causes can be considered unreasonable or unnecessary. For example, various tunneling situations cross the MTU by very little as they add just a header's worth of data. The addition is small, but each packet now has to be sent in two fragments, the second of which carries very little payload. The same amount of payload is being moved, but every intermediate router has to do double the work in terms of header parsing and routing decisions. * As it is normal to maximize the payload in every fragment, in general as well as when fragmenting, any further fragmentation that turns out to be necessary will increase the overhead even more. * There is no simple method to discover the MTU of links beyond a node's direct peers. The Internet Protocol requires that hosts must be able to process IP datagrams of at least 576 bytes (for IPv4) or 1280 bytes (for IPv6). However, this does not preclude Data Link Layers with an MTU smaller than IP's minimum MTU from conveying IP data. For example, according to IPv6's specification, if a particular Data Link Layer physically cannot deliver an IP datagram of 1280 bytes in a single frame, then the link layer MUST provide its own fragmentation and reassembly mechanism, separate from IP's own fragmentation mechanism, to ensure that a 1280-byte IP datagram can be delivered, intact, to the IP layer. ===Path MTU Discovery=== {{Main|Path MTU Discovery}} The Internet Protocol defines the "Path MTU" of an Internet transmission path as the smallest MTU of any of the IP [[Hop (telecommunications)|hop]]s of the "path" between a source and destination. Put another way, the path MTU is the largest packet size that can traverse this path without suffering fragmentation. RFC 1191 (IPv4) and RFC 1981 (IPv6) describe "Path MTU Discovery", a technique for determining the path MTU between two IP hosts. It works by setting the DF (Don't Fragment) option in the IP headers of outgoing packets. Any device along the path whose MTU is smaller than the packet will drop such packets and send back an [[Internet Control Message Protocol|ICMP]] "[[ICMP Destination Unreachable|Destination Unreachable (Datagram Too Big)]]" message containing its MTU. This information allows the source host to reduce its assumed path MTU appropriately. The process repeats until the MTU becomes small enough to traverse the entire path without fragmentation. Unfortunately, increasing numbers of networks [[Black hole (networking)|drop ICMP traffic]] (e.g. to prevent [[denial-of-service attack]]s), which prevents path MTU discovery from working. One often detects such blocking in the cases where a connection works for low-volume data but hangs as soon as a host sends a large block of data at a time. For example, with [[Internet Relay Chat|IRC]] a connecting [[Client (computing)|client]] might see the initial messages up to and including the initial [[ping]] (sent by the server as an [[anti spoofing measure]]), but get no response after that. This is because the large set of welcome messages are sent out in packets bigger than the real MTU. Also, in an IP network, the path from the source address to the destination address often gets modified dynamically, in response to various events ([[load balancing (computing)|load-balancing]], [[Network congestion|congestion]], [[Downtime|outages]], etc.) - this could result in the path MTU changing (sometimes repeatedly) during a transmission, which may introduce further packet drops before the host finds the new safe MTU. Most [[Ethernet]] [[Local area network|LAN]]s use an MTU of 1500 bytes (modern LANs can use [[Jumbo frame]]s, allowing for an MTU up to 9000 bytes); however, border protocols like [[Point-to-Point Protocol over Ethernet|PPPoE]] will reduce this. The difference between the MTU seen by end-nodes (e.g. 1500) and the Path MTU causes Path MTU Discovery to come into effect, with the possible result of making some sites behind badly-configured [[Firewall (networking)|firewall]]s unreachable. One can possibly work around this, depending on which part of the network one controls; for example one can change the MSS ([[maximum segment size]]) in the initial packet that sets up the [[Transmission Control Protocol|TCP]] connection at one's firewall. RFC 4821, Packetization Layer Path MTU Discovery, describes a Path MTU Discovery technique which responds more robustly to ICMP filtering. ==ATM backbones, an example of MTU tuning== {{Expert-subject|Computer Networking|date=February 2009}} Sometimes the demands of efficiency encourage artificially declaring a reduced MTU in software below the true maximum possible length supported - for example: where an ATM ([[Asynchronous Transfer Mode]]) network carries IP traffic. Some providers, particularly those with a telephony background, use ATM on their internal backbone network. ATM operates at optimum efficiency when packet length is a multiple of 48 bytes. This is because ATM is sent as a stream of fixed-length packets (known as 'cells'), each of which can carry a payload of 48 bytes of user data with 5 bytes of overhead for a total cost of 53 bytes per cell. So the total length of the transmitted data length is 53 * ncells bytes, where ncells = the number of required cells of = INT((payload_length+47)/48). So in the worst case, where the total length = (48*n+1) bytes, one additional cell is needed to transmit the one last byte of payload, the final cell costing an extra 53 transmitted bytes 47 of which are padding. For this reason, artificially declaring a reduced MTU in software maximises protocol efficiency at the ATM layer by making the ATM [[AAL5]] total payload length a multiple of 48 bytes whenever possible. For example, 31 completely filled ATM cells carry a payload of 31*48=1488 bytes. Taking this figure of 1488 and subtracting from it any overheads contributed by all relevant higher protocols we can obtain a suggested value for an artificially-reduced optimal MTU. In the case where the user would normally send 1500 byte packets, sending between 1489 and 1536 bytes requires an additional fixed cost of 53 bytes transmitted, in the form of one extra ATM cell. For the example of IP over [[Digital Subscriber Line|DSL]] connections using [[PPPoA]]/[[VC-MUX]], again choosing to fill 31 ATM cells as before, we obtain a desired optimal reduced MTU figure of 1478 = 31*48-10 taking into account an overhead of 10 bytes consisting of a [[Point-to-Point Protocol]] overhead of 2 bytes, and an AAL5 overhead of 8 bytes. This gives a total cost of 31*53=1643 bytes transmitted via ATM from a 1478 byte packet passed to PPPoA. In the case of IP sent over ADSL using PPPoA the figure of 1478 would be the total length of the IP packet including IP headers. So in this example, keeping to a self-imposed reduced MTU of 1478 as opposed to sending IP packets of total length 1500 saves 53 bytes per packet at the ATM layer at a cost of a 22 byte reduction of the length of IP packets. RFC 2516 prescribes a maximum MTU for [[PPPoE]]/DSL connections of 1492: a PPPoE header of 6 bytes, leaving enough room for a 1488 byte payload, or 31 full ATM cells. ==MTU in other standards== The [[G.hn]] standard, developed by [[ITU-T]], provides a high-speed (up to 1 Gigabit/s) [[local area network]] using existing home wiring ([[Power line communication|power lines]], phone lines and [[Ethernet over coax|coaxial cables]]). The G.hn [[Data Link Layer]] accepts data frames of up to 2¹⁴ bytes (16384 bytes). In order to avoid the problem of long data-frames taking up the medium for long periods of time, G.hn defines a procedure for [[segmentation]] that divides the data frame into smaller segments. ==Disruption== The transmission of a [[packet (information technology)|packet]] on a physical network segment that is larger than the segment's MTU is known as ''jabber''. This is almost always caused by faulty devices. Many [[network switch]]es have a built-in capability to detect when a device is jabbering and block it until it resumes proper operation.<ref>[http://support.3com.com/infodeli/tools/switches/ss3/management/ug/cli_mg6a.htm 3Com SuperStack Switch Management Guide] </ref> ==See also== * [[Computer networking]] * [[Ethernet]] ==References== {{Reflist}} * {{Cite web|url=http://alive.znep.com/~marcs/mtu/index.html |title=Path MTU Discovery and Filtering ICMP |author=Marc Slemko |date=January 18, 1998 |accessdate=2007-09-02}} ==External links== * [http://www.orangeproblems.co.uk/kitz/ Tweaking your MTU / RWin for Orange Broadband Users] * [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TCPMSSTARGET How to set the TCP MSS value using iptables] * [http://help.expedient.net/broadband/mtu_ping_test.shtml Discovering of MTU value] via [[ping]] and setting it in [[Microsoft Windows]] * [http://www.dslreports.com/drtcp DrTCP]&nbsp;– a utility for optimizing MTU under Microsoft Windows * [http://www.elifulkerson.com/projects/mturoute.php mturoute]&nbsp;– a console utility for debugging mtu problems * [http://www.phildev.net/mss/ MSS Initiative] * [http://www.iea-software.com/products/mtupath.cfm MTU Path] &nbsp; MTU discovery tool for IPv4 and IPv6 networks {{DEFAULTSORT:Maximum Transmission Unit}} [[Category:Packets (information technology)]] [[cs:Maximum transmission unit]] [[da:Maximum Transmission Unit]] [[de:Maximum Transmission Unit]] [[es:Unidad máxima de transferencia]] [[fr:Maximum Transmission Unit]] [[id:Unit Transmisi Maksimum]] [[it:Maximum Transmission Unit]] [[he:Maximum Transmission Unit]] [[ms:Unit penghantaran maksimum]] [[ja:Maximum Transmission Unit]] [[pl:Maximum Transmission Unit]] [[pt:MTU]] [[ru:MTU]] [[sv:Maximum Transmission Unit]] [[uk:MTU]] [[zh:最大传输单元]]'