draft-ietf-tsvwg-datagram-plpmtud-15.txt   draft-ietf-tsvwg-datagram-plpmtud-16.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen
approved) M. Tuexen approved) M. Tuexen
Intended status: Standards Track I. Ruengeler Intended status: Standards Track I. Ruengeler
Expires: 27 August 2020 T. Voelker Expires: 10 September 2020 T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
24 February 2020 9 March 2020
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-15 draft-ietf-tsvwg-datagram-plpmtud-16
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 27 August 2020. This Internet-Draft will expire on 10 September 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
skipping to change at page 3, line 43 skipping to change at page 3, line 43
6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 33 6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 33
6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 34 6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 34
6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34
6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 34 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 34
6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 34 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 34
6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 35 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 35
6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 35 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 35
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 39 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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
skipping to change at page 13, line 39 skipping to change at page 13, line 39
The DPLPMTUD method relies upon the PL sender being able to generate The DPLPMTUD method relies upon the PL sender being able to generate
probe packets with a specific size. TCP is able to generate these probe packets with a specific size. TCP is able to generate these
probe packets by choosing to appropriately segment data being sent probe packets by choosing to appropriately segment data being sent
[RFC4821]. In contrast, a datagram PL that constructs a probe packet [RFC4821]. In contrast, a datagram PL that constructs a probe packet
has to either request an application to send a data block that is has to either request an application to send a data block that is
larger than that generated by an application, or to utilize padding larger than that generated by an application, or to utilize padding
functions to extend a datagram beyond the size of the application functions to extend a datagram beyond the size of the application
data block. Protocols that permit exchange of control messages data block. Protocols that permit exchange of control messages
(without an application data block) can generate a probe packet by (without an application data block) can generate a probe packet by
extending a control message with padding data. extending a control message with padding data. The total size of a
probe packet includes all headers and padding added to the payload
data being sent (e.g., including protocol option fields, security-
related fields such as an AEAD tag and TLS record layer padding).
A receiver is REQUIRED to be able to distinguish an in-band data A receiver is REQUIRED to be able to distinguish an in-band data
block from any added padding. This is needed to ensure that any block from any added padding. This is needed to ensure that any
added padding is not passed on to an application at the receiver. added padding is not passed on to an application at the receiver.
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 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 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.
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 Probing using application data: A probe packet that contains a data
block supplied by an application that matches the size of the block supplied by an application that matches the size of the
probe packet. This method requests the application to issue a probe packet. This method requests the application to issue a
data block of the desired probe size. If the application/ data block of the desired probe size.
transport needs protection from the loss of an unsuccessful probe
packet, the application/transport needs then to perform transport-
layer retransmission/repair of the data block (e.g., by
retransmission after loss is detected).
A PL that uses a probe packet carrying an application data block, A PL that uses a probe packet carrying an application data and needs
could need to retransmit this application data block if the probe protection from the loss of this probe packet, could perform
fails, possibly using a smaller PLPMTU. This could need the PL to to transport-layer retransmission/repair of the data block (e.g., by
use a smaller packet size to traverse the end-to-end path (which retransmission after loss is detected or by duplicating the data
could utilize endpoint network-layer or a PL that can re-segment the block in a datagram without the padding data). This retransmited
data block into multiple datagrams). data block might possibly need to be sent using a smaller PLPMTU,
which could need the PL to to use a smaller packet size to traverse
the end-to-end path. (This could utilize endpoint network-layer or a
PL that can re-segment the data block into multiple datagrams).
DPLPMTUD MAY choose to use only one of these methods to simplify the DPLPMTUD MAY choose to use only one of these methods to simplify the
implementation. implementation.
Probe messages sent by a PL MUST contain enough information to Probe messages sent by a PL MUST contain enough information to
uniquely identify the probe within Maximum Segment Lifetime, while uniquely identify the probe within Maximum Segment Lifetime, while
being robust to reordering and replay of probe response and PTB being robust to reordering and replay of probe response and PTB
messages. messages.
4.2. Confirmation of Probed Packet Size 4.2. Confirmation of Probed Packet Size
skipping to change at page 16, line 9 skipping to change at page 16, line 9
When the method detects the current PLPMTU is not supported, DPLPMTUD When the method detects the current PLPMTU is not supported, DPLPMTUD
sets a lower PLPMTU, and sets a lower MPS. The PL then confirms that sets a lower PLPMTU, and sets a lower MPS. The PL then confirms that
the new PLPMTU can be successfully used across the path. A probe the new PLPMTU can be successfully used across the path. A probe
packet could need to have a size less than the size of the data block packet could need to have a size less than the size of the data block
generated by the application. generated by the application.
4.4. The Maximum Packet Size (MPS) 4.4. The Maximum Packet Size (MPS)
The result of probing determines a usable PLPMTU, which is used to The result of probing determines a usable PLPMTU, which is used to
set the MPS used by the application. The MPS is smaller than the set the MPS used by the application. The MPS is smaller than the
PLPMTU because of the presence of PL headers and any IP options or PLPMTU because it is reduced by the size of PL headers (including the
extensions added to the PL packet. The relationship between the MPS overhead of security-related fields such as an AEAD tag and TLS
and the PLPMTUD is illustrated in Figure 1. record layer padding) and any IP options or extensions added to the
PL packet. The relationship between the MPS and the PLPMTUD is
illustrated in Figure 1.
any additional any additional
headers .--- MPS -----. headers .--- MPS -----.
| | | | | |
v v v v v v
+------------------------------+ +------------------------------+
| IP | ** | PL | protocol data | | IP | ** | PL | protocol data |
+------------------------------+ +------------------------------+
<---------- PLPMTU ------------> <---------- PLPMTU ------------>
skipping to change at page 36, line 44 skipping to change at page 36, line 44
identifies the need for robustness in the method because the path identifies the need for robustness in the method because the path
information might be inconsistent. information might be inconsistent.
A node performing DPLPMTUD could experience conflicting information A node performing DPLPMTUD could experience conflicting information
about the size of supported probe packets. This could occur when about the size of supported probe packets. This could occur when
there are multiple paths are concurrently in use and these exhibit a there are multiple paths are concurrently in use and these exhibit a
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.
DPLPMTUD methods can introduce padding data to inflate the length of
the datagram to the total size required for a probe packet. The
total size of a probe packet includes all headers and padding added
to the payload data being sent (e.g., including security-related
fields such as an AEAD tag and TLS record layer padding). The value
of the padding data does not influence the DPLPMTUD search algorithm,
and therefore needs to be set consistent with the policy of the PL.
If a PL can make use of cryptographic confidentiality or data-
integrity mechanisms, then adding anything (e.g., padding) for
DPLPMTUD that is not protected by those cryptographic mechanisms is
an anti-pattern to be avoided.
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", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020, draft-ietf-quic-transport-27, 21 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.txt>. transport-27.txt>.
 End of changes. 11 change blocks. 
27 lines changed or deleted 39 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/