draft-ietf-tsvwg-datagram-plpmtud-10.txt   draft-ietf-tsvwg-datagram-plpmtud-11.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: 21 May 2020 I. Ruengeler Expires: 23 May 2020 I. Ruengeler
T. Voelker T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
18 November 2019 20 November 2019
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-10 draft-ietf-tsvwg-datagram-plpmtud-11
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 21 May 2020. This Internet-Draft will expire on 23 May 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 17 skipping to change at page 11, line 17
6. Probe loss recovery: It is RECOMMENDED to use probe packets that 6. Probe loss recovery: It is RECOMMENDED to use probe packets that
do not carry any user data that would require retransmission if do not carry any user data that would require retransmission if
lost. Most datagram transports permit this. If a probe packet lost. Most datagram transports permit this. If a probe packet
contains user data requiring retransmission in case of loss, the contains user data requiring retransmission in case of loss, the
PL (or layers above) are REQUIRED to arrange any retransmission/ PL (or layers above) are REQUIRED to arrange any retransmission/
repair of any resulting loss. DPLPMTUD is REQUIRED to be robust repair of any resulting loss. DPLPMTUD is REQUIRED to be robust
in the case where probe packets are lost due to other reasons in the case where probe packets are lost due to other reasons
(including link transmission error, congestion). (including link transmission error, congestion).
7. Loss of a probe packet SHOULD NOT be treated as an indication of 7. Probing and congestion control: The DPLPMTUD sender treats
congestion. The loss of a probe packet SHOULD NOT directly isolated loss of a probe packet (with or without a corresponding
trigger a congestion control reaction [RFC4821] because this PTB message) as a potential indication of a PMTU limit for the
could result in unecessary reduction of the sending rate. The path. Loss of a probe packet SHOULD NOT be treated as an
interval between probe packets MUST be at least one RTT. indication of congestion. The loss of a probe packet SHOULD NOT
directly trigger a congestion control reaction [RFC4821] because
this could result in unecessary reduction of the sending rate.
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 in the destination cache and used by other PL
instances. The specification of PLPMTUD [RFC4821] states: "If instances. The specification of PLPMTUD [RFC4821] states: "If
PLPMTUD updates the MTU for a particular path, all Packetization PLPMTUD updates the MTU for a particular path, all Packetization
Layer sessions that share the path representation (as described Layer sessions that share the path representation (as described
in Section 5.2 of [RFC4821]) SHOULD be notified to make use of in Section 5.2 of [RFC4821]) SHOULD be notified to make use of
the new MTU". Such methods MUST be robust to the wide variety of the new MTU". Such methods MUST be robust to the wide variety of
underlying network forwarding behaviors. Section 5.2 of underlying network forwarding behaviors. Section 5.2 of
[RFC8201] provides guidance on the caching of PMTU information [RFC8201] provides guidance on the caching of PMTU information
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 OR PTB_SIZE == 0 PTB_SIZE < MIN_MTU
* Invalid PTB_SIZE. * 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
skipping to change at page 20, line 43 skipping to change at page 20, line 43
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.
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. unsuccessful probe packets that have been sent. Each
time a probe packet is acknowledged, the value is set
to zero.
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 27, line 23 skipping to change at page 27, line 23
is started. The timer is canceled when the PL receives is started. The timer is canceled when the PL receives
acknowledgment that the probe packet has been successfully sent acknowledgment that the probe packet has been successfully sent
across the path Section 4.1. This confirms that the PROBED_SIZE is across the path Section 4.1. This confirms that the PROBED_SIZE is
supported, and the PROBED_SIZE value is then assigned to the PLPMTU. supported, and the PROBED_SIZE value is then assigned to the PLPMTU.
The search algorithm can continue to send subsequent probe packets of The search algorithm can continue to send subsequent probe packets of
an increasing size. an increasing size.
If the timer expires before a probe packet is acknowledged, the probe If the timer expires before a probe packet is acknowledged, the probe
has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER
expires, the PROBE_COUNT is incremented, the PROBE_TIMER is expires, the PROBE_COUNT is incremented, the PROBE_TIMER is
reinitialized, and a new probe of the same size or any other sized reinitialized, and a new probe of the same size or any other size
(determined by the search algorithm) can be sent. The maximum number (determined by the search algorithm) can be sent. The maximum number
of consecutive failed probes is configured (MAX_PROBES). If the of consecutive failed probes is configured (MAX_PROBES). If the
value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and
the PL sender enters the SEARCH_COMPLETE state. the PL sender enters the SEARCH_COMPLETE state.
5.3.2. Selection of Probe Sizes 5.3.2. Selection of Probe Sizes
The search algorithm needs to determine a minimum useful gain in The search algorithm needs to determine a minimum useful gain in
PLPMTU. It would not be constructive for a PL sender to attempt to PLPMTU. It would not be constructive for a PL sender to attempt to
probe for all sizes. This would incur unnecessary load on the path probe for all sizes. This would incur unnecessary load on the path
skipping to change at page 32, line 37 skipping to change at page 32, line 37
6.2.3.4. Handling of PTB Messages by SCTP/DTLS 6.2.3.4. Handling of PTB Messages by SCTP/DTLS
It is not possible to perform ICMP validation as specified in It is not possible to perform ICMP validation as specified in
[RFC4960], since even if the ICMP message payload contains sufficient [RFC4960], since even if the ICMP message payload contains sufficient
information, the reflected SCTP common header would be encrypted. information, the reflected SCTP common header would be encrypted.
Therefore it is not possible to process PTB messages at the PL. Therefore it is not possible to process PTB messages at the PL.
6.3. DPLPMTUD for QUIC 6.3. DPLPMTUD for QUIC
Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a QUIC [I-D.ietf-quic-transport] is a UDP-based transport that provides
UDP-based transport that provides reception feedback. The UDP reception feedback. The UDP payload includes the QUIC packet header,
payload includes the QUIC packet header, protected payload, and any protected payload, and any authentication fields. QUIC depends on a
authentication fields. QUIC depends on a PMTU of at least 1280 PMTU of at least 1280 bytes.
bytes.
Section 14.1 of [I-D.ietf-quic-transport] describes the path Section 14.1 of [I-D.ietf-quic-transport] describes the path
considerations when sending QUIC packets. It recommends the use of considerations when sending QUIC packets. It recommends the use of
PADDING frames to build the probe packet. Pure probe-only packets PADDING frames to build the probe packet. Pure probe-only packets
are constructed with PADDING frames and PING frames to create a are constructed with PADDING frames and PING frames to create a
padding only packet that will elicit an acknowledgement. Such padding only packet that will elicit an acknowledgement. Such
padding only packets enable probing without affecting the transfer of padding only packets enable probing without affecting the transfer of
other QUIC frames. other QUIC frames.
The recommendation for QUIC endpoints implementing DPLPMTUD is that a The recommendation for QUIC endpoints implementing DPLPMTUD is that a
 End of changes. 9 change blocks. 
18 lines changed or deleted 22 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/