--- 1/draft-ietf-tsvwg-datagram-plpmtud-13.txt 2020-02-12 02:13:43.656824768 -0800 +++ 2/draft-ietf-tsvwg-datagram-plpmtud-14.txt 2020-02-12 02:13:43.744827048 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones -Updates4821, 4960, 8085 (if approved) University of Aberdeen +Updates: 4821, 4960, 8085 (if approved) University of Aberdeen Intended status: Standards Track M. Tuexen -Expires: 23 July 2020 I. Ruengeler +Expires: 15 August 2020 I. Ruengeler T. Voelker Muenster University of Applied Sciences - 20 January 2020 + 12 February 2020 Packetization Layer Path MTU Discovery for Datagram Transports - draft-ietf-tsvwg-datagram-plpmtud-13 + draft-ietf-tsvwg-datagram-plpmtud-14 Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet @@ -48,91 +48,102 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 23 July 2020. + This Internet-Draft will expire on 15 August 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 10 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 13 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 14 - 4.3. Black Hole Detection . . . . . . . . . . . . . . . . . . 14 + 4.3. Black Hole Detection . . . . . . . . . . . . . . . . . . 15 4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 15 4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 16 4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 17 4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 17 4.6.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 18 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 19 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 20 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 21 5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 22 5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 23 - 5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 25 - 5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 28 - 5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 28 - 5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 29 - 5.3.3. Resilience to Inconsistent Path Information . . . . . 30 - 5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 30 - 6. Specification of Protocol-Specific Methods . . . . . . . . . 30 - 6.1. Application support for DPLPMTUD with UDP or - UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 30 - 6.1.1. Application Request . . . . . . . . . . . . . . . . . 31 - 6.1.2. Application Response . . . . . . . . . . . . . . . . 31 - 6.1.3. Sending Application Probe Packets . . . . . . . . . . 31 - 6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 31 - 6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 32 - 6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 32 - 6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32 - 6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32 - 6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33 - 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34 - 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 35 - 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 35 - 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 35 - 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 36 - 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 36 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 10.2. Informative References . . . . . . . . . . . . . . . . . 39 - Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 + 5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 24 + 5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 27 + 5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 27 + 5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 28 + 5.3.3. Resilience to Inconsistent Path Information . . . . . 28 + 5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 29 + 6. Specification of Protocol-Specific Methods . . . . . . . . . 29 + 6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 29 + 6.1.1. Application Request . . . . . . . . . . . . . . . . . 30 + 6.1.2. Application Response . . . . . . . . . . . . . . . . 30 + 6.1.3. Sending Application Probe Packets . . . . . . . . . . 30 + 6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 30 + 6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 30 + 6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 30 + 6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 31 + 6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 31 + 6.2.1.1. Initial Connectivity . . . . . . . . . . . . . . 31 + 6.2.1.2. Sending SCTP Probe Packets . . . . . . . . . . . 31 + 6.2.1.3. Validating the Path with SCTP . . . . . . . . . . 32 + 6.2.1.4. PTB Message Handling by SCTP . . . . . . . . . . 32 + 6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 32 + 6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 32 + 6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 32 + 6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 32 + 6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 33 + 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 33 + 6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 33 + 6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 33 + 6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 33 + 6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 33 + 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 33 + 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 34 + 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 34 + 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 34 + 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 34 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 10.2. Informative References . . . . . . . . . . . . . . . . . 38 + Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The IETF has specified datagram transport using UDP, SCTP, and DCCP, as well as protocols layered on top of these transports (e.g., SCTP/ UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP network layer. This document describes a robust method for Path MTU Discovery (PMTUD) that can be used with these transport protocols (or the applications that use their transport service) to discover an appropriate size of packet to use across an Internet path. @@ -593,22 +604,21 @@ This results in three possible ways that a sender can create a probe packet: Probing using padding data: A probe packet that contains only control information together with any padding, which is needed to be inflated to the size of the probe packet. Since these probe packets do not carry an application-supplied data block, they do not typically require retransmission, although they do still consume network capacity and incur endpoint processing. - Probing using application data and padding - data: A probe packet that + Probing using application data and padding data: A probe packet that contains a data block supplied by an application that is combined with padding to inflate the length of the datagram to the size of the probe packet. If the application/transport needs protection from the loss of this probe packet, the application/transport could perform transport-layer retransmission/repair of the data block (e.g., by retransmission after loss is detected or by duplicating the data block in a datagram without the padding data). Probing using application data: A probe packet that contains a data @@ -729,21 +739,21 @@ been sent with a size less than the MPS and the PLPMTU was subsequently reduced. If these packets are lost, the PL MAY segment the data using the new MPS. If a PL is unable to re-segment a previously sent datagram (e.g., [RFC4960]), then the sender either discards the datagram or could perform retransmission using network- layer fragmentation to form multiple IP packets not larger than the PLPMTU. For IPv4, the use of endpoint fragmentation by the sender is preferred over clearing the DF-bit in the IPv4 header. Operational experience reveals that IP fragmentation can reduce the reliability of Internet communication [I-D.ietf-intarea-frag-fragile], which may - reduce the success of retransmission + reduce the success of retransmission. 4.5. Disabling the Effect of PMTUD A PL implementing this specification MUST suspend network layer processing of outgoing packets that enforces a PMTU [RFC1191][RFC8201] for each flow utilising DPLPMTUD, and instead use DPLPMTUD to control the size of packets that are sent by a flow. This removes the need for the network layer to drop or fragment sent packets that have a size greater than the PMTU. @@ -909,117 +919,104 @@ 5.1. DPLPMTUD Components This section describes the timers, constants, and variables of DPLPMTUD. 5.1.1. Timers The method utilizes up to three timers: - PROBE_TIMER: The PROBE_TIMER is configured to expire after a - period longer than the maximum time to receive - an acknowledgment to a probe packet. This value - MUST NOT be smaller than 1 second, and SHOULD be - larger than 15 seconds. Guidance on selection - of the timer value are provided in section 3.1.1 - of the UDP Usage Guidelines [RFC8085]. + PROBE_TIMER: The PROBE_TIMER is configured to expire after a period + longer than the maximum time to receive an acknowledgment to a + probe packet. This value MUST NOT be smaller than 1 second, and + SHOULD be larger than 15 seconds. Guidance on selection of the + timer value are provided in section 3.1.1 of the UDP Usage + Guidelines [RFC8085]. - PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period - a sender will continue to use the current - PLPMTU, after which it re-enters the Search - phase. This timer has a period of 600 seconds, + PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period a + sender will continue to use the current PLPMTU, after which it re- + enters the Search phase. This timer has a period of 600 seconds, as recommended by PLPMTUD [RFC4821]. - DPLPMTUD MAY inhibit sending probe packets when - no application data has been sent since the - previous probe packet. A PL preferring to use - an up-to-data PMTU once user data is sent again, - can choose to continue PMTU discovery for each - path. However, this could result in sending - additional packets. + DPLPMTUD MAY inhibit sending probe packets when no application + data has been sent since the previous probe packet. A PL + preferring to use an up-to-data PMTU once user data is sent again, + can choose to continue PMTU discovery for each path. However, + this could result in sending additional packets. CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST - NOT be used. For other PLs, the - CONFIRMATION_TIMER is configured to the period a - PL sender waits before confirming the current - PLPMTU is still supported. This is less than - the PMTU_RAISE_TIMER and used to decrease the - PLPMTU (e.g., when a black hole is encountered). - Confirmation needs to be frequent enough when - data is flowing that the sending PL does not - black hole extensive amounts of traffic. - Guidance on selection of the timer value are - provided in section 3.1.1 of the UDP Usage - Guidelines [RFC8085]. + NOT be used. For other PLs, the CONFIRMATION_TIMER is configured + to the period a PL sender waits before confirming the current + PLPMTU is still supported. This is less than the PMTU_RAISE_TIMER + and used to decrease the PLPMTU (e.g., when a black hole is + encountered). Confirmation needs to be frequent enough when data + is flowing that the sending PL does not black hole extensive + amounts of traffic. Guidance on selection of the timer value are + provided in section 3.1.1 of the UDP Usage Guidelines [RFC8085]. - DPLPMTUD MAY inhibit sending probe packets when - no application data has been sent since the - previous probe packet. A PL preferring to use - an up-to-data PMTU once user data is sent again, - can choose to continue PMTU discovery for each - path. However, this could result in sending - additional packets. + DPLPMTUD MAY inhibit sending probe packets when no application + data has been sent since the previous probe packet. A PL + preferring to use an up-to-data PMTU once user data is sent again, + can choose to continue PMTU discovery for each path. However, + this could result in sending additional packets. An implementation could implement the various timers using a single timer. 5.1.2. Constants The following constants are defined: MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT - counter (see Section 5.1.3). MAX_PROBES represents the - limit for the number of consecutive probe attempts of - any size. The default value of MAX_PROBES is 3. This - value is greater than 1 to provide robustness to - isolated packet loss. + counter (see Section 5.1.3). MAX_PROBES represents the limit for + the number of consecutive probe attempts of any size. Search + algorithms benefit from a MAX_PROBES value greater than 1 because + this can provide robustness to isolated packet loss. The default + value of MAX_PROBES is 3. MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size. - For IPv6, this value is 1280 bytes, as specified in - [RFC8200]. For IPv4, the minimum value is 68 bytes. + For IPv6, this value is 1280 bytes, as specified in [RFC8200]. + For IPv4, the minimum value is 68 bytes. - Note: An IPv4 router is required to be able to forward a - datagram of 68 bytes without further fragmentation. - This is the combined size of an IPv4 header and the - minimum fragment size of 8 bytes. In addition, - receivers are required to be able to reassemble - fragmented datagrams at least up to 576 bytes, as stated - in section 3.3.3 of [RFC1122]. + Note: An IPv4 router is required to be able to forward a datagram + of 68 bytes without further fragmentation. This is the combined + size of an IPv4 header and the minimum fragment size of 8 bytes. + In addition, receivers are required to be able to reassemble + fragmented datagrams at least up to 576 bytes, as stated in + section 3.3.3 of [RFC1122]. MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to - be less than or equal to the minimum of the local MTU of - the outgoing interface and the destination PMTU for - receiving. An application, or PL, MAY choose a smaller - MAX_PMTU when there is no need to send packets larger - than a specific size. + be less than or equal to the minimum of the local MTU of the + outgoing interface and the destination PMTU for receiving. An + application, or PL, MAY choose a smaller MAX_PMTU when there is no + need to send packets larger than a specific size. BASE_PMTU: The BASE_PMTU is a configured size expected to work for - most paths. The size is equal to or larger than the - MIN_PMTU and smaller than the MAX_PMTU. In the case of - IPv6, this value is 1280 bytes [RFC8200]. When using - IPv4, a size of 1200 bytes is RECOMMENDED. + most paths. The size is equal to or larger than the MIN_PMTU and + smaller than the MAX_PMTU. In the case of IPv6, this value is + 1280 bytes [RFC8200]. When using IPv4, a size of 1200 bytes is + RECOMMENDED. 5.1.3. Variables This method utilizes a set of variables: PROBED_SIZE: The PROBED_SIZE is the size of the current probe - packet. This is a tentative value for the PLPMTU, - which is awaiting confirmation by an acknowledgment. + packet. This is a tentative value for the PLPMTU, which is + awaiting confirmation by an acknowledgment. PROBE_COUNT: The PROBE_COUNT is a count of the number of successive - unsuccessful probe packets that have been sent. Each - time a probe packet is acknowledged, the value is set - to zero. (Some probe loss is expected while searching, - therefore loss of a single probe is not an indication - of a PMTU problem.) + unsuccessful probe packets that have been sent. Each time a probe + packet is acknowledged, the value is set to zero. (Some probe + loss is expected while searching, therefore loss of a single probe + is not an indication of a PMTU problem.) The figure below illustrates the relationship between the packet size constants and variables at a point of time when the DPLPMTUD algorithm performs path probing to increase the size of the PLPMTU. A probe packet has been sent of size PROBED_SIZE. Once this is acknowledged, the PLPMTU will raise to PROBED_SIZE allowing the DPLPMTUD algorithm to further increase PROBED_SIZE towards the actual PMTU. MIN_PMTU MAX_PMTU @@ -1059,71 +1056,62 @@ | timer | | algorithm | expired | | completed | | | | | v | +-----------------+ +---| Search Complete | +-----------------+ Figure 4: DPLPMTUD Phases - Base: The Base Phase confirms connectivity to the remote - peer using packets of the BASE_PMTU. This phase is - implicit for a connection-oriented PL (where it can - be performed in a PL connection handshake). A - connectionless PL sends an acknowledged probe - packet to confirm that the remote peer is - reachable. The sender also confirms that BASE_PMTU - is supported across the network path. + Base: The Base Phase confirms connectivity to the remote peer using + packets of the BASE_PMTU. This phase is implicit for a + connection-oriented PL (where it can be performed in a PL + connection handshake). A connectionless PL sends an acknowledged + probe packet to confirm that the remote peer is reachable. The + sender also confirms that BASE_PMTU is supported across the + network path. - A PL that does not wish to support a path with a - PLPMTU less than BASE_PMTU can simplify the phase - into a single step by performing the connectivity - checks with a probe of the BASE_PMTU size. + A PL that does not wish to support a path with a PLPMTU less than + BASE_PMTU can simplify the phase into a single step by performing + the connectivity checks with a probe of the BASE_PMTU size. - Once confirmed, DPLPMTUD enters the Search Phase. - If this phase fails to confirm, DPLPMTUD enters the - Error Phase. + Once confirmed, DPLPMTUD enters the Search Phase. If this phase + fails to confirm, DPLPMTUD enters the Error Phase. - Search: The Search Phase utilizes a search algorithm to - send probe packets to seek to increase the PLPMTU. - The algorithm concludes when it has found a - suitable PLPMTU, by entering the Search Complete - Phase. + Search: The Search Phase utilizes a search algorithm to send probe + packets to seek to increase the PLPMTU. The algorithm concludes + when it has found a suitable PLPMTU, by entering the Search + Complete Phase. - A PL could respond to PTB messages using the PTB to - advance or terminate the search, see Section 4.6. + A PL could respond to PTB messages using the PTB to advance or + terminate the search, see Section 4.6. Search Complete: The Search Complete Phase is entered when the - PLPMTU is supported across the network path. A PL - can use a CONFIRMATION_TIMER to periodically repeat - a probe packet for the current PLPMTU size. If the - sender is unable to confirm reachability (e.g., if - the CONFIRMATION_TIMER expires) or the PL signals a - lack of reachability, DPLPMTUD enters the Base - phase. + PLPMTU is supported across the network path. A PL can use a + CONFIRMATION_TIMER to periodically repeat a probe packet for the + current PLPMTU size. If the sender is unable to confirm + reachability (e.g., if the CONFIRMATION_TIMER expires) or the PL + signals a lack of reachability, DPLPMTUD enters the Base phase. - The PMTU_RAISE_TIMER is used to periodically resume - the search phase to discover if the PLPMTU can be - raised. Black Hole Detection causes the sender to - enter the Base Phase. + The PMTU_RAISE_TIMER is used to periodically resume the search + phase to discover if the PLPMTU can be raised. Black Hole + Detection causes the sender to enter the Base Phase. - Error: The Error Phase is entered when there is - conflicting or invalid PLPMTU information for the - path (e.g. a failure to support the BASE_PMTU) that - cause DPLPMTUD to be unable to progress and the - PLPMTU is lowered. + Error: The Error Phase is entered when there is conflicting or + invalid PLPMTU information for the path (e.g. a failure to support + the BASE_PMTU) that cause DPLPMTUD to be unable to progress and + the PLPMTU is lowered. - DPLPMTUD remains in the Error Phase until a - consistent view of the path can be discovered and - it has also been confirmed that the path supports - the BASE_PMTU (or DPLPMTUD is suspended). + DPLPMTUD remains in the Error Phase until a consistent view of the + path can be discovered and it has also been confirmed that the + path supports the BASE_PMTU (or DPLPMTUD is suspended). An implementation that only reduces the PLPMTU to a suitable size would be sufficient to ensure reliable operation, but can be very inefficient when the actual PMTU changes or when the method (for whatever reason) makes a suboptimal choice for the PLPMTU. A full implementation of DPLPMTUD provides an algorithm enabling the DPLPMTUD sender to increase the PLPMTU following a change in the characteristics of the path, such as when a link is reconfigured with a larger MTU, or when there is a change in the set of links traversed @@ -1174,109 +1162,92 @@ +----+ PTB: PTB_SIZE = PLPMTU +----+ CONFIRMATION_TIMER expiry: PROBE_TIMER expiry: PROBE_COUNT < MAX_PROBES or PROBE_COUNT < MAX_PROBES or PLPMTU Probe acked Probe acked or PTB: PLPMTU < PTB_SIZE < PROBED_SIZE Figure 5: State machine for Datagram PLPMTUD The following states are defined: - DISABLED: The DISABLED state is the initial state before - probing has started. It is also entered from any - other state, when the PL indicates loss of - connectivity. This state is left, once the PL + DISABLED: The DISABLED state is the initial state before probing has + started. It is also entered from any other state, when the PL + indicates loss of connectivity. This state is left, once the PL indicates connectivity to the remote PL. - BASE: The BASE state is used to confirm that the - BASE_PMTU size is supported by the network path and - is designed to allow an application to continue - working when there are transient reductions in the - actual PMTU. It also seeks to avoid long periods - when a sender searching for a larger PLPMTU is - unaware that packets are not being delivered due to - a packet or ICMP Black Hole. + BASE: The BASE state is used to confirm that the BASE_PMTU size is + supported by the network path and is designed to allow an + application to continue working when there are transient + reductions in the actual PMTU. It also seeks to avoid long + periods when a sender searching for a larger PLPMTU is unaware + that packets are not being delivered due to a packet or ICMP Black + Hole. - On entry, the PROBED_SIZE is set to the BASE_PMTU - size and the PROBE_COUNT is set to zero. + On entry, the PROBED_SIZE is set to the BASE_PMTU size and the + PROBE_COUNT is set to zero. - Each time a probe packet is sent, the PROBE_TIMER - is started. The state is exited when the probe - packet is acknowledged, and the PL sender enters - the SEARCHING state. + Each time a probe packet is sent, the PROBE_TIMER is started. The + state is exited when the probe packet is acknowledged, and the PL + sender enters the SEARCHING state. - The state is also left when the PROBE_COUNT reaches - MAX_PROBES or a received PTB message is validated. - This causes the PL sender to enter the ERROR state. + The state is also left when the PROBE_COUNT reaches MAX_PROBES or + a received PTB message is validated. This causes the PL sender to + enter the ERROR state. - SEARCHING: The SEARCHING state is the main probing state. - This state is entered when probing for the - BASE_PMTU was successful. + SEARCHING: The SEARCHING state is the main probing state. This + state is entered when probing for the BASE_PMTU was successful. - Each time a probe packet is acknowledged, the - PROBE_COUNT is set to zero, the PLPMTU is set to - the PROBED_SIZE and then the PROBED_SIZE is - increased using the search algorithm. + Each time a probe packet is acknowledged, the PROBE_COUNT is set + to zero, the PLPMTU is set to the PROBED_SIZE and then the + PROBED_SIZE is increased using the search algorithm. - When a probe packet is sent and not acknowledged - within the period of the PROBE_TIMER, the - PROBE_COUNT is incremented and a new probe packet - is transmitted. + When a probe packet is sent and not acknowledged within the period + of the PROBE_TIMER, the PROBE_COUNT is incremented and a new probe + packet is transmitted. - The state is exited to enter SEARCH_COMPLETE when - the PROBE_COUNT reaches MAX_PROBES, a validated PTB - is received that corresponds to the last - successfully probed size (PTB_SIZE = PLPMTU), or a - probe of size MAX_PMTU is acknowledged (PLPMTU = - MAX_PMTU). + The state is exited to enter SEARCH_COMPLETE when the PROBE_COUNT + reaches MAX_PROBES, a validated PTB is received that corresponds + to the last successfully probed size (PTB_SIZE = PLPMTU), or a + probe of size MAX_PMTU is acknowledged (PLPMTU = MAX_PMTU). - When a black hole is detected in the SEARCHING - state, this causes the PL sender to enter the BASE - state. + When a black hole is detected in the SEARCHING state, this causes + the PL sender to enter the BASE state. SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates a successful - end to the SEARCHING state. DPLPMTUD remains in - this state until either the PMTU_RAISE_TIMER - expires or a black hole is detected. + end to the SEARCHING state. DPLPMTUD remains in this state until + either the PMTU_RAISE_TIMER expires or a black hole is detected. - When DPLPMTUD uses an unacknowledged PL and is in - the SEARCH_COMPLETE state, a CONFIRMATION_TIMER - periodically resets the PROBE_COUNT and schedules a - probe packet with the size of the PLPMTU. If - MAX_PROBES successive PLPMTUD sized probes fail to - be acknowledged the method enters the BASE state. - When used with an acknowledged PL (e.g., SCTP), - DPLPMTUD SHOULD NOT continue to generate PLPMTU - probes in this state. + When DPLPMTUD uses an unacknowledged PL and is in the + SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets + the PROBE_COUNT and schedules a probe packet with the size of the + PLPMTU. If MAX_PROBES successive PLPMTUD sized probes fail to be + acknowledged the method enters the BASE state. When used with an + acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to + generate PLPMTU probes in this state. - ERROR: The ERROR state represents the case where either - the network path is not known to support a PLPMTU - of at least the BASE_PMTU size or when there is - contradictory information about the network path - that would otherwise result in excessive variation - in the MPS signalled to the higher layer. The - state implements a method to mitigate oscillation - in the state-event engine. It signals a - conservative value of the MPS to the higher layer - by the PL. The state is exited when packet probes - no longer detect the error or when the PL indicates - that connectivity has been lost. The PL sender - then enters the SEARCHING state. + ERROR: The ERROR state represents the case where either the network + path is not known to support a PLPMTU of at least the BASE_PMTU + size or when there is contradictory information about the network + path that would otherwise result in excessive variation in the MPS + signalled to the higher layer. The state implements a method to + mitigate oscillation in the state-event engine. It signals a + conservative value of the MPS to the higher layer by the PL. The + state is exited when packet probes no longer detect the error. + The PL sender then enters the SEARCHING state. - Implementations are permitted to enable endpoint - fragmentation if the DPLPMTUD is unable to validate - MIN_PMTU within PROBE_COUNT probes. If DPLPMTUD is - unable to validate MIN_PMTU the implementation will - transition to the DISABLED state. + Implementations are permitted to enable endpoint fragmentation if + the DPLPMTUD is unable to validate MIN_PMTU within PROBE_COUNT + probes. If DPLPMTUD is unable to validate MIN_PMTU the + implementation will transition to the DISABLED state. - Note: MIN_PMTU could be identical to BASE_PMTU, - simplifying the actions in this state. + Note: MIN_PMTU could be identical to BASE_PMTU, simplifying the + actions in this state. 5.3. Search to Increase the PLPMTU This section describes the algorithms used by DPLPMTUD to search for a larger PLPMTU. 5.3.1. Probing for a larger PLPMTU Implementations use a search algorithm across the search range to determine whether a larger PLPMTU can be supported across a network @@ -1701,22 +1672,22 @@ different PMTU. If not considered, this could result in packets not being delivered (black holed) when the PLPMTU is larger than the smallest actual PMTU. 10. References 10.1. Normative References [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", draft-ietf-quic-transport-20 (work - in progress), 23 April 2019, + and Secure Transport", Work in Progress, Internet-Draft, + draft-ietf-quic-transport-20, 23 April 2019, . [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . @@ -1770,30 +1741,29 @@ [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . 10.2. Informative References [I-D.ietf-intarea-frag-fragile] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., - and F. Gont, "IP Fragmentation Considered Fragile", draft- - ietf-intarea-frag-fragile-17 (work in progress), 30 - September 2019, - . + and F. Gont, "IP Fragmentation Considered Fragile", Work + in Progress, Internet-Draft, draft-ietf-intarea-frag- + fragile-17, 30 September 2019, . [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet - Architecture", draft-ietf-intarea-tunnels-10 (work in - progress), 12 September 2019, + Architecture", Work in Progress, Internet-Draft, draft- + ietf-intarea-tunnels-10, 12 September 2019, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, @@ -2010,30 +1982,32 @@ * Shorten a diagram line. * Address nits from Julius and Wes. * Be clearer when talking about IP layer caches Authors' Addresses Godred Fairhurst University of Aberdeen - School of Engineering, Fraser Noble Building + School of Engineering + Fraser Noble Building Aberdeen AB24 3UE United Kingdom Email: gorry@erg.abdn.ac.uk Tom Jones University of Aberdeen - School of Engineering, Fraser Noble Building + School of Engineering + Fraser Noble Building Aberdeen AB24 3UE United Kingdom Email: tom@erg.abdn.ac.uk Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt