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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/