--- 1/draft-ietf-tsvwg-datagram-plpmtud-10.txt 2019-11-20 03:13:13.724547498 -0800 +++ 2/draft-ietf-tsvwg-datagram-plpmtud-11.txt 2019-11-20 03:13:13.804549542 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones Updates4821 (if approved) University of Aberdeen Intended status: Standards Track M. Tuexen -Expires: 21 May 2020 I. Ruengeler +Expires: 23 May 2020 I. Ruengeler T. Voelker Muenster University of Applied Sciences - 18 November 2019 + 20 November 2019 Packetization Layer Path MTU Discovery for Datagram Transports - draft-ietf-tsvwg-datagram-plpmtud-10 + draft-ietf-tsvwg-datagram-plpmtud-11 Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a network @@ -41,21 +41,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 21 May 2020. + This Internet-Draft will expire on 23 May 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -482,25 +482,28 @@ 6. Probe loss recovery: It is RECOMMENDED to use probe packets that do not carry any user data that would require retransmission if lost. Most datagram transports permit this. If a probe packet contains user data requiring retransmission in case of loss, the PL (or layers above) are REQUIRED to arrange any retransmission/ repair of any resulting loss. DPLPMTUD is REQUIRED to be robust in the case where probe packets are lost due to other reasons (including link transmission error, congestion). - 7. Loss of a probe packet SHOULD NOT be treated as an 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. + 7. Probing and congestion control: The DPLPMTUD sender treats + isolated loss of a probe packet (with or without a corresponding + PTB message) as a potential indication of a PMTU limit for the + path. Loss of a probe packet SHOULD NOT be treated as an + 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 corresponding entry in the destination cache and used by other PL instances. The specification of PLPMTUD [RFC4821] states: "If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described 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 underlying network forwarding behaviors. Section 5.2 of [RFC8201] provides guidance on the caching of PMTU information @@ -729,22 +732,22 @@ 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 indicated PTB_SIZE is less than the size used by probe packets and larger than minimum size accepted. 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 set of variables: - PTB_SIZE < MIN_MTU OR PTB_SIZE == 0 - * Invalid PTB_SIZE. + PTB_SIZE < MIN_MTU + * Invalid PTB_SIZE see Section 4.5.1. * PTB message ought to be discarded without further processing (e. g. PLPMTU not modified). * The information could be utilized as an input to trigger enabling a resilience mode. MIN_PMTU < PTB_SIZE < BASE_PMTU * 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 @@ -921,21 +924,23 @@ 5.1.3. Variables This method utilizes a set of variables: PROBED_SIZE: The PROBED_SIZE is the size of the current probe packet. This is a tentative value for the PLPMTU, which is awaiting confirmation by an acknowledgment. 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 constants and variables at a point of time when the DPLPMTUD algorithm performs path probing to increase the size of the PLPMTU. A probe packet has been sent of size PROBED_SIZE. Once this is acknowledged, the PLPMTU will raise to PROBED_SIZE allowing the DPLPMTUD algorithm to further increase PROBED_SIZE towards the actual PMTU. MIN_PMTU MAX_PMTU @@ -1208,21 +1213,21 @@ is started. The timer is canceled when the PL receives acknowledgment that the probe packet has been successfully sent 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. The search algorithm can continue to send subsequent probe packets of an increasing size. If the timer expires before a probe packet is acknowledged, the probe has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER 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 of consecutive failed probes is configured (MAX_PROBES). If the value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and the PL sender enters the SEARCH_COMPLETE state. 5.3.2. Selection of Probe Sizes The search algorithm needs to determine a minimum useful gain in 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 @@ -1462,25 +1467,24 @@ 6.2.3.4. Handling of PTB Messages by SCTP/DTLS It is not possible to perform ICMP validation as specified in [RFC4960], since even if the ICMP message payload contains sufficient information, the reflected SCTP common header would be encrypted. Therefore it is not possible to process PTB messages at the PL. 6.3. DPLPMTUD for QUIC - Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a - UDP-based transport that provides reception feedback. The UDP - payload includes the QUIC packet header, protected payload, and any - authentication fields. QUIC depends on a PMTU of at least 1280 - bytes. + QUIC [I-D.ietf-quic-transport] is a UDP-based transport that provides + reception feedback. The UDP payload includes the QUIC packet header, + protected payload, and any authentication fields. QUIC depends on a + PMTU of at least 1280 bytes. Section 14.1 of [I-D.ietf-quic-transport] describes the path considerations when sending QUIC packets. It recommends the use of PADDING frames to build the probe packet. Pure probe-only packets are constructed with PADDING frames and PING frames to create a padding only packet that will elicit an acknowledgement. Such padding only packets enable probing without affecting the transfer of other QUIC frames. The recommendation for QUIC endpoints implementing DPLPMTUD is that a