draft-ietf-tsvwg-datagram-plpmtud-11.txt   draft-ietf-tsvwg-datagram-plpmtud-12.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Updates4821 (if approved) University of Aberdeen Updates4821 (if approved) University of Aberdeen
Intended status: Standards Track M. Tuexen Intended status: Standards Track M. Tuexen
Expires: 23 May 2020 I. Ruengeler Expires: 7 June 2020 I. Ruengeler
T. Voelker T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
20 November 2019 5 December 2019
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-11 draft-ietf-tsvwg-datagram-plpmtud-12
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 network detect and reduce the message size when a sender encounters a network
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 May 2020. This Internet-Draft will expire on 7 June 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 11, line 27 skipping to change at page 11, line 27
7. Probing and congestion control: The DPLPMTUD sender treats 7. Probing and congestion control: The DPLPMTUD sender treats
isolated loss of a probe packet (with or without a corresponding isolated loss of a probe packet (with or without a corresponding
PTB message) as a potential indication of a PMTU limit for the PTB message) as a potential indication of a PMTU limit for the
path. Loss of a probe packet SHOULD NOT be treated as an path. Loss of a probe packet SHOULD NOT be treated as an
indication of congestion. The loss of a probe packet SHOULD NOT indication of congestion. The loss of a probe packet SHOULD NOT
directly trigger a congestion control reaction [RFC4821] because directly trigger a congestion control reaction [RFC4821] because
this could result in unecessary reduction of the sending rate. this could result in unecessary reduction of the sending rate.
The interval between probe packets MUST be at least one RTT. The interval between probe packets MUST be at least one RTT.
8. Shared PLPMTU state: The PLPMTU value MAY also be stored with the 8. Shared PLPMTU state: The PLPMTU value MAY also be stored with the
corresponding entry in the destination cache and used by other PL corresponding entry associated with the destination in the IP
instances. The specification of PLPMTUD [RFC4821] states: "If layer cache, and used by other PL instances. The specification
PLPMTUD updates the MTU for a particular path, all Packetization of PLPMTUD [RFC4821] states: "If PLPMTUD updates the MTU for a
Layer sessions that share the path representation (as described particular path, all Packetization Layer sessions that share the
in Section 5.2 of [RFC4821]) SHOULD be notified to make use of path representation (as described in Section 5.2 of [RFC4821])
the new MTU". Such methods MUST be robust to the wide variety of SHOULD be notified to make use of the new MTU". Such methods
underlying network forwarding behaviors. Section 5.2 of MUST be robust to the wide variety of underlying network
[RFC8201] provides guidance on the caching of PMTU information forwarding behaviors. Section 5.2 of [RFC8201] provides guidance
and also the relation to IPv6 flow labels. on the caching of PMTU information and also the relation to IPv6
flow labels.
In addition, the following principles are stated for design of a In addition, the following principles are stated for design of a
DPLPMTUD method: DPLPMTUD method:
* MPS: A method is REQUIRED to signal an appropriate MPS to the * MPS: A method is REQUIRED to signal an appropriate MPS to the
higher layer using the PL. The value of the MPS can change higher layer using the PL. The value of the MPS can change
following a change to the path. It is RECOMMENDED that methods following a change to the path. It is RECOMMENDED that methods
avoid forcing an application to use an arbitrary small MPS avoid forcing an application to use an arbitrary small MPS
(PLPMTU) for transmission while the method is searching for the (PLPMTU) for transmission while the method is searching for the
currently supported PLPMTU. Datagram PLs do not necessarily currently supported PLPMTU. Datagram PLs do not necessarily
skipping to change at page 16, line 30 skipping to change at page 16, line 30
A set of checks are intended to provide protection from a router that A set of checks are intended to provide protection from a router that
reports an unexpected PTB_SIZE. The PL also needs to check that the reports an unexpected PTB_SIZE. The PL also needs to check that the
indicated PTB_SIZE is less than the size used by probe packets and indicated PTB_SIZE is less than the size used by probe packets and
larger than minimum size accepted. larger than minimum size accepted.
This section provides a summary of how PTB messages can be utilized. This section provides a summary of how PTB messages can be utilized.
This processing depends on the PTB_SIZE and the current value of a This processing depends on the PTB_SIZE and the current value of a
set of variables: set of variables:
PTB_SIZE < MIN_MTU PTB_SIZE < MIN_PMTU
* Invalid PTB_SIZE see Section 4.5.1. * Invalid PTB_SIZE see Section 4.5.1.
* PTB message ought to be discarded without further processing * PTB message ought to be discarded without further processing
(e. g. PLPMTU not modified). (e. g. PLPMTU not modified).
* The information could be utilized as an input to trigger * The information could be utilized as an input to trigger
enabling a resilience mode. enabling a resilience mode.
MIN_PMTU < PTB_SIZE < BASE_PMTU MIN_PMTU < PTB_SIZE < BASE_PMTU
* A robust PL MAY enter an error state (see Section 5.2) for an * A robust PL MAY enter an error state (see Section 5.2) for an
IPv4 path when the PTB_SIZE reported in the PTB message is IPv4 path when the PTB_SIZE reported in the PTB message is
larger than or equal to 68 bytes and when this is less than the larger than or equal to 68 bytes [RFC0791] and when this is
BASE_PMTU. less than the BASE_PMTU.
* A robust PL MAY enter an error state (see Section 5.2) for an * A robust PL MAY enter an error state (see Section 5.2) for an
IPv6 path when the PTB_SIZE reported in the PTB message is IPv6 path when the PTB_SIZE reported in the PTB message is
larger than or equal to 1280 bytes and when this is less than larger than or equal to 1280 bytes [RFC8200] and when this is
the BASE_PMTU. less than the BASE_PMTU.
PTB_SIZE = PLPMTU PTB_SIZE = PLPMTU
* Completes the search for a larger PLPMTU. * Completes the search for a larger PLPMTU.
PTB_SIZE > PROBED_SIZE PTB_SIZE > PROBED_SIZE
* Inconsistent network signal. * Inconsistent network signal.
* PTB message ought to be discarded without further processing * PTB message ought to be discarded without further processing
(e. g. PLPMTU not modified). (e. g. PLPMTU not modified).
skipping to change at page 20, line 11 skipping to change at page 20, line 11
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 the number of consecutive probe attempts of limit for the number of consecutive probe attempts of
any size. The default value of MAX_PROBES is 3. This any size. The default value of MAX_PROBES is 3. This
value is greater than 1 to provide robustness to value is greater than 1 to provide robustness to
isolated packet loss. isolated packet loss.
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
[RFC2460]. For IPv4, the minimum value is 68 bytes. [RFC8200]. 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 of 68 bytes without further fragmentation. datagram of 68 bytes without further fragmentation.
This is the combined size of an IPv4 header and the This is the combined size of an IPv4 header and the
minimum fragment size of 8 bytes. In addition, minimum fragment size of 8 bytes. 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 fragmented datagrams at least up to 576 bytes, as stated
in 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 outgoing interface and the destination PMTU for the outgoing interface and the destination PMTU for
receiving. An application, or PL, MAY choose a smaller receiving. An application, or PL, MAY choose a smaller
MAX_PMTU when there is no need to send packets larger MAX_PMTU when there is no 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 smaller than the MAX_PMTU. In the case of MIN_PMTU and smaller than the MAX_PMTU. In the case of
IPv6, this value is 1280 bytes [RFC2460]. When using IPv6, this value is 1280 bytes [RFC8200]. When using
IPv4, a size of 1200 bytes is RECOMMENDED. IPv4, a size of 1200 bytes is 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 awaiting confirmation by an acknowledgment. which is awaiting confirmation by an acknowledgment.
skipping to change at page 21, line 33 skipping to change at page 21, line 33
Section 5.2. Section 5.2.
+------+ +------+
+------->| Base |----------------+ Connectivity +------->| Base |----------------+ Connectivity
| +------+ | or BASE_PMTU | +------+ | or BASE_PMTU
| | | confirmation failed | | | confirmation failed
| | v | | v
| | Connectivity +-------+ | | Connectivity +-------+
| | and BASE_PMTU | Error | | | and BASE_PMTU | Error |
| | confirmed +-------+ | | confirmed +-------+
| | | | | | Consistent
| v | Consistent connectivity | v | connectivity
PLPMTU | +--------+ | and BASE_PMTU PLPMTU | +--------+ | and BASE_PMTU
confirmation | | Search |<--------------+ confirmed confirmation | | Search |<--------------+ confirmed
failed | +--------+ failed | +--------+
| ^ | | ^ |
| | | | | |
| Raise | | Search | Raise | | Search
| timer | | algorithm | timer | | algorithm
| expired | | completed | expired | | completed
| | | | | |
| | v | | v
skipping to change at page 28, line 49 skipping to change at page 28, line 49
The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do
not define a method in the RFC-series that supports PLPMTUD. In not define a method in the RFC-series that supports PLPMTUD. In
particular, the UDP transport does not provide the transport layer particular, the UDP transport does not provide the transport layer
features needed to implement datagram PLPMTUD. features needed to implement datagram PLPMTUD.
The DPLPMTUD method can be implemented as a part of an application The DPLPMTUD method can be implemented as a part of an application
built directly or indirectly on UDP or UDP-Lite, but relies on built directly or indirectly on UDP or UDP-Lite, but relies on
higher-layer protocol features to implement the method [RFC8085]. higher-layer protocol features to implement the method [RFC8085].
Some primitives used by DPLPMTUD might not be available via the Some primitives used by DPLPMTUD might not be available via the
Datagram API (e.g., the ability to access the PLPMTU cache, or Datagram API (e.g., the ability to access the PLPMTU from the IP
interpret received PTB messages). layer cache, or interpret received PTB messages).
In addition, it is desirable that PMTU discovery is not performed by In addition, it is desirable that PMTU discovery is not performed by
multiple protocol layers. An application SHOULD avoid using DPLPMTUD multiple protocol layers. An application SHOULD avoid using DPLPMTUD
when the underlying transport system provides this capability. To when the underlying transport system provides this capability. To
use common method for managing the PLPMTU has benefits, both in the use common method for managing the PLPMTU has benefits, both in the
ability to share state between different processes and opportunities ability to share state between different processes and opportunities
to coordinate probing. to coordinate probing.
6.1.1. Application Request 6.1.1. Application Request
skipping to change at page 34, line 11 skipping to change at page 34, line 11
validation as specified in Section 5.2 of [RFC8085] therefore apply. validation as specified in Section 5.2 of [RFC8085] therefore apply.
In addition to UDP Port validation QUIC can validate an ICMP message In addition to UDP Port validation QUIC can validate an ICMP message
by looking for valid Connection IDs in the quoted packet. by looking for valid Connection IDs in the quoted packet.
7. Acknowledgements 7. Acknowledgements
This work was partially funded by the European Union's Horizon 2020 This work was partially funded by the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). The views expressed are solely those of the author(s). (NEAT). The views expressed are solely those of the author(s).
Thanks to all that have commented or contributed, the TSVWG and QUIC
working groups, and Mathew Calder and Julius Flohr for providing
implementations.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
If there are no requirements for IANA, the section will be removed If there are no requirements for IANA, the section will be removed
during conversion into an RFC by the RFC Editor. during conversion into an RFC by the RFC Editor.
9. Security Considerations 9. Security Considerations
The security considerations for the use of UDP and SCTP are provided The security considerations for the use of UDP and SCTP are provided
skipping to change at page 35, line 33 skipping to change at page 35, line 36
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", draft-ietf-quic-transport-20 (work
in progress), 23 April 2019, in progress), 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,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery",
RFC 1191, DOI 10.17487/RFC1191, November 1990, RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
2004, <https://www.rfc-editor.org/info/rfc3828>. 2004, <https://www.rfc-editor.org/info/rfc3828>.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
Parameter for the Stream Control Transmission Protocol Parameter for the Stream Control Transmission Protocol
(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
<https://www.rfc-editor.org/info/rfc4820>. <https://www.rfc-editor.org/info/rfc4820>.
skipping to change at page 36, line 28 skipping to change at page 36, line 30
<https://www.rfc-editor.org/info/rfc6951>. <https://www.rfc-editor.org/info/rfc6951>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[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>.
skipping to change at page 41, line 9 skipping to change at page 41, line 17
* Address comments from Lars Eggert * Address comments from Lars Eggert
* Reinforce that PROBE_COUNT is successive attempts to probe for any * Reinforce that PROBE_COUNT is successive attempts to probe for any
size size
* Redefine MAx_PROBES to 3 * Redefine MAx_PROBES to 3
* Address PTB_SIZE of 0 or less that MIN_PMTU * Address PTB_SIZE of 0 or less that MIN_PMTU
Working group draft -11:
* Restore a sentence removed in previous rev
* De-acronymise QUIC
* Address some nits
Working group draft -12:
* Add TSVWG, QUIC and implementers to acknowledgements
* Shorten a diagram line
* Address nits from Julius and Wes
* 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
 End of changes. 17 change blocks. 
28 lines changed or deleted 56 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/