Annotated Bibliography of MTU Related Publications

This bibliography is still far from complete. Contributions welcome!

Current Path MTU Discovery Standards

[RFC4821]
M. Mathis, J. Heffner "Packetization Layer Path MTU Discovery," March 2007.
Abstract: "This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively."
It is our intent that this algorithm is sufficient to support diverse MTUs in all Internet environments.

[RFC1191]
J.C. Mogul, S.E. Deering, "Path MTU discovery," Nov 1990. [rfc1191.txt]
Abstract: "This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice."
See [RFC2923] for an extensive discussion of the problems with RFC1191.

[RFC1981]
J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6," August 1996. [rfc1981.txt]
Abstract: "This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4."

Papers about MTU and Network Performance

[RJSVL07]
W. Rutherford, L. Jorgenson, M. Siegert, P. Van Epp, L. Liu, "16,000-64,000 B pMTU experiments with simulation: The case for super jumbo frames at Supercomputing '05", Nov 2006. [DOI]
Abstract: This paper presents a case study including the results and preliminary simulations for a series of Ethernet-based Xnet "super jumbo frame" (SJF) experiments conducted prior to and at Supercomputing '05, for up-to-64 000 B path MTU. As far as we are aware, the first public supercomputing demonstration of a router passing 64 000 B frames was performed in our Xnet SJF booth. While Gigabit Ethernet based network architectures typically show reduced zero payload node latency performance relative to interconnect solutions (Myrinet, SP Switch and InfiniBand), some with higher path MTU equivalent, Ethernet continues to be the most widely deployed and may remain so for the forseeable future. Cumulative jumbo frame research spanning several years, combined with theoretical calculations and extrapolations from experimental data obtained during Supercomputing '05 indicates the possible practical feasibility of SJF-based network mechanics as a potential means to realize practical long term performance goals for high throughput streaming. Some of the lessons and implications of the SJF approach are discussed in relation to the evolution of novel network architectures, particularly in relation to explicit path systems for the high performance computing community, pending deployment of 40 and/or 100 Gb Ethernet.

Other Current IETF Documents

[RFC4459]
P. Savola, "MTU and Fragmentation Issues with In-the-Network Tunneling," April 2006.
Abstract: "Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length."
This document presents a very thorough discussion of the interactions between MTU, tunnels and classical path MTU discovery. Unfortunately it clashes slightly with RFC4821, which was published later. When RFC4821 is fully deployed, it will always be preferable to toss oversized datagrams, even if ICMP messages are not being delivered. In the interim, tunnel implementations that use some form of hidden fragmentation should be cognizant of the fact that delivering oversized probes defeats RFC4821 path MTU discovery and will cause end-systems to chooses inefficient MTUs. It is imperative that implementations that follow some of the suggestions in RFC4459 have some mechanism to identify MTU probes, and assure that they are not delivered inappropriately.

[RFC2923]
K. Lahey "TCP Problems with Path MTU Discovery," September 2000. [rfc2923.txt]
Abstract: "This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowledgments (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU."

Historical IETF documents

[RFC2401]
S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol," [rfc2401.txt]
Good commentary about interactions between path MTU discovery and IPsec.

[RFC1435]
S. Knowles, "IESG Advice from Experience with Path MTU Discovery," March 1993. [rfc1435.txt]
Abstract: "In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery."

[RFC1063]
J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie, "IP MTU discovery options," Jul 1988. [rfc1063.txt]
Abstract: "A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol."
Obsoleted by RFC1191.

Mailing list & WG archives

[IPng]
IPng discussion of MTU and tunnels ca Aug 1999
[Full IPng Mail Archive] [Culled by Fred Templin]
A good discussion of MTU discovery and tunnels in the context of RFC 2529 (6over4).

[MTUDWG]
IP MTU Discovery (mtudisc) working group.
[Mail Archive Nov 89 - Feb 95] [Mail Archive Jul 03 - Apr 07]
This WG was active for two seperate time intervals around the development of RFC 1191 and RFC 4821.

[TCP-IP]
TCP-IP Mailing list May 1987 - March 1989
[Full Mail Archive] [Abridged by Fred Templin]
The first message o the abridged archive on 5/22/87 was from Art Berggreen and appears to be the start of the debate that has continued on to this day. This sequence of messages occurred during the time frame in which "Fragmentation Considered Harmful" was published.

Thanks to Fred Templin for collecting and distilling the mailing list archives.

Other Publications

A white paper by Alteon Extended Frame Sized for Next Generation Ethernets. The original dead link can be seen [here]. Thanks to Loki Jorgenson for locating an archived copy at http://web.archive.org/.
Selina Lo, Alteon Networks Jumbo Frames? Yes!
Bernard Daines, Packet Engines Jumbo Frames? No!

This page is http://www.psc.edu/~mathis/MTU/bibliography.html.

For additional information check out these pages: Raising the Internet MTU, Pittsburgh Supercomputing Center, Network research at PSC, or Matt Mathis. Please send comments and suggestions to mathis@psc.edu.

Current Path MTU Discovery Standards
[RFC4821]	M. Mathis, J. Heffner "Packetization Layer Path MTU Discovery," March 2007. Abstract: "This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively." It is our intent that this algorithm is sufficient to support diverse MTUs in all Internet environments.
[RFC1191]	J.C. Mogul, S.E. Deering, "Path MTU discovery," Nov 1990. [rfc1191.txt] Abstract: "This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice." See [RFC2923] for an extensive discussion of the problems with RFC1191.
[RFC1981]	J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6," August 1996. [rfc1981.txt] Abstract: "This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4."
Papers about MTU and Network Performance
[RJSVL07]	W. Rutherford, L. Jorgenson, M. Siegert, P. Van Epp, L. Liu, "16,000-64,000 B pMTU experiments with simulation: The case for super jumbo frames at Supercomputing '05", Nov 2006. [DOI] Abstract: This paper presents a case study including the results and preliminary simulations for a series of Ethernet-based Xnet "super jumbo frame" (SJF) experiments conducted prior to and at Supercomputing '05, for up-to-64 000 B path MTU. As far as we are aware, the first public supercomputing demonstration of a router passing 64 000 B frames was performed in our Xnet SJF booth. While Gigabit Ethernet based network architectures typically show reduced zero payload node latency performance relative to interconnect solutions (Myrinet, SP Switch and InfiniBand), some with higher path MTU equivalent, Ethernet continues to be the most widely deployed and may remain so for the forseeable future. Cumulative jumbo frame research spanning several years, combined with theoretical calculations and extrapolations from experimental data obtained during Supercomputing '05 indicates the possible practical feasibility of SJF-based network mechanics as a potential means to realize practical long term performance goals for high throughput streaming. Some of the lessons and implications of the SJF approach are discussed in relation to the evolution of novel network architectures, particularly in relation to explicit path systems for the high performance computing community, pending deployment of 40 and/or 100 Gb Ethernet.
Other Current IETF Documents
[RFC4459]	P. Savola, "MTU and Fragmentation Issues with In-the-Network Tunneling," April 2006. Abstract: "Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length." This document presents a very thorough discussion of the interactions between MTU, tunnels and classical path MTU discovery. Unfortunately it clashes slightly with RFC4821, which was published later. When RFC4821 is fully deployed, it will always be preferable to toss oversized datagrams, even if ICMP messages are not being delivered. In the interim, tunnel implementations that use some form of hidden fragmentation should be cognizant of the fact that delivering oversized probes defeats RFC4821 path MTU discovery and will cause end-systems to chooses inefficient MTUs. It is imperative that implementations that follow some of the suggestions in RFC4459 have some mechanism to identify MTU probes, and assure that they are not delivered inappropriately.
[RFC2923]	K. Lahey "TCP Problems with Path MTU Discovery," September 2000. [rfc2923.txt] Abstract: "This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowledgments (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU."
Historical IETF documents
[RFC2401]	S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol," [rfc2401.txt] Good commentary about interactions between path MTU discovery and IPsec.
[RFC1435]	S. Knowles, "IESG Advice from Experience with Path MTU Discovery," March 1993. [rfc1435.txt] Abstract: "In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery."
[RFC1063]	J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie, "IP MTU discovery options," Jul 1988. [rfc1063.txt] Abstract: "A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol." Obsoleted by RFC1191.
Mailing list & WG archives
[IPng]	IPng discussion of MTU and tunnels ca Aug 1999 [Full IPng Mail Archive] [Culled by Fred Templin] A good discussion of MTU discovery and tunnels in the context of RFC 2529 (6over4).
[MTUDWG]	IP MTU Discovery (mtudisc) working group. [Mail Archive Nov 89 - Feb 95] [Mail Archive Jul 03 - Apr 07] This WG was active for two seperate time intervals around the development of RFC 1191 and RFC 4821.
[TCP-IP]	TCP-IP Mailing list May 1987 - March 1989 [Full Mail Archive] [Abridged by Fred Templin] The first message o the abridged archive on 5/22/87 was from Art Berggreen and appears to be the start of the debate that has continued on to this day. This sequence of messages occurred during the time frame in which "Fragmentation Considered Harmful" was published.