Internet Engineering Task Force P. S. Kim Internet-Draft TU Korea Intended status: Informational Expires: 25 April 2024 23 October 2023 An Alternative Path MTU Discovery for QUIC draft-pskim-quic-pmtud-00 Abstract This draft describes an alternative Path MTU Discovery (PMTUD) for QUIC. RFC 8899 searches for PMTU by sending a probe at the QUIC layer, which is an active probing approach. In this draft, a passive probing approach is adopted to discover the PMTU. The process of discovering the PMTU is not performed separately, but is performed simultaneously in the actual application data communication. That is, the actual application data is allowed to be carried in the process of discovering the PMTU. A probe packet is defined newly using 1-RTT packet which includes actual application data as well as a short packet header and a PING_EXT frame. The PING_EXT frame is also defined newly. Until the best PMTU is discovered, the size of the probe packet is changed according to the size of the PMTU candidate. A simple discovery algorithm using only the PMTU candidate sequence with linear upward is described in this draft. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 25 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. P.S. Kim Expires 25 April 2024 [Page 1] Internet-Draft An Alternative Path MTU Discovery for QUIC October 2023 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Active Probing for PMTUD with QUIC . . . . . . . . . . . . . 3 3. Passive Probing for PMTUD with QUIC . . . . . . . . . . . . . 4 3.1. A New PMTU Probe Packet . . . . . . . . . . . . . . . . . 4 3.2. Passive Probing . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The maximum transmission unit (MTU) is the largest size frame or packet - in bytes or octets - that can be transmitted across a data link. It is most used in reference to packet size on an Ethernet network using the Internet Protocol (IP). The Path MTU (PMTU) is the smallest MTU of all involved network interfaces for a network path and limits the size of IP packets. A PMTU Discovery (PMTUD) is a standardized technique in computer networking for determining the PMTU size on the network path between two IP hosts, usually with the goal of avoiding IP fragmentation for IPv4[RFC1191] and for IPv6[RFC8201]. When a packet too large for the path was sent, the PMTUD expects to receive a Packet Too Big (PTB) message. However, there are multiple reasons why a PTB message might not arrive at the sender. Therefore, the PMTUD for the Packetization Layer (PL) that selects the size of IP packets is specified recently in [RFC8899]. RFC8899 works without a signal from the network and covers generic PL protocols such as QUIC of [RFC9000]. Meanwhile, [UDP-PMTUD] complements RFC8899 by specifying how a UDP Options sender implements Datagram PL PMTUD(DPLPMTUD). It allows a datagram application to discover the largest size of datagram that can be sent across a specific network path. However, RFC8899 does not contain details about how to discovery for the best PMTU. P.S. Kim Expires 25 April 2024 [Page 2] Internet-Draft An Alternative Path MTU Discovery for QUIC October 2023 Recently, therefore, [Q-PMTUD] complements RFC8899 by presenting a discovery algorithm with QUIC. Using the discovery algorithm with a set of possible PMTU candidates and their possible probing sequences, the best PMTU is obtained. However, to discover the best PMTU, some probe packets which have no semantic value might be injecting into network, which is called active probing or active measurement. The active probing approach can increase a network load and perturb the network. Based on [Q-PMTUD] and [UDP-PMTUD], this draft consider an alternative PMTUD for QUIC. To discover the best PMTU, the passive probing approach is adopted. The process of discovering the best PMTU is not carried out separately, but is carried out simultaneously in the actual application data communication. A probe packet is defined newly using 1-RTT packet which includes actual application data as well as a short packet header and a PING_EXT frame. The PING_EXT frame is also defined newly. Until the best PMTU is discovered, the size of the probe packet is changed according to the size of the PMTU candidate. A simple discovery algorithm using only the PMTU candidate sequence with linear upward is described in this draft. Other rather complex discovery algorithms that consider various PMTU candidate sequences will be dealt with in the future. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Active Probing for PMTUD with QUIC[Q-PMTUD] The specification of QUIC in RFC9000 recommends to use the PMTUD framework of RFC8899. RFC 8899 DPLPMTUD has the following phases: Base: Send the probe in its basic size first. QUIC assumes that the specified 1280 bytes pass, so it starts from the next phase. Search: Search for candidate PMTUs while sending probes. Once the best PMTU is detected, proceed to the next phase. Search Complete: Since PMTU may change due to route changes, check if it is still the best. However, RFC8899 does not contain details about how to discovery for the best PMTU. Therefore, [Q-PMTUD] complements the specification, RFC8899, by presenting a discovery algorithm with QUIC. From a practical point of view, it might be a good choice to consider only a set of common PMTU values. However, the PMTU value may usually change over time. Thus, P.S. Kim Expires 25 April 2024 [Page 3] Internet-Draft An Alternative Path MTU Discovery for QUIC October 2023 [Q-PMTUD] considers a set of possible PMTU candidates. PMTU candidates are values every 4 bytes from 1280 bytes to 1500 bytes. Then, a discovery algorithm is proposed, which probes one PMTU candidate after the other. This means, it starts the probe for the next candidate not before the probe for the current candidate either succeeded or failed. Then endpoint uses this discovery algorithm that repeatedly chooses PMTU candidates to probe. The candidate sequence is required to specify the order in which the discovery algorithm probes PMTU candidates. The endpoint must choose a PMTU candidate larger than the largest successfully probed candidate and smaller than any other probed candidate with a lost probe packet. Seven candidate sequences are considered, evaluated, and compared in [Q-PMTUD]. To probe one PMTU candidate, according to RFC9000, the endpoint builds a probe packet with a short packet header, a PING frame and PADDING frames. The endpoint controls the size of the probe packet by the number of PADDING frames, whose size is one byte each. The PING frame makes the packet ack-eliciting. However, to discover the best PMTU, some probe packets which have no semantic value might be injecting into network, which is thus called active measurement or active probing. This active probing approach can increase a network load and perturb the network. 3. Passive Probing for PMTUD with QUIC There are three possible ways to create a PMTU probe packet as follows[RFC8899]: - Probing using padding data - Probing using application data and padding data - Probing using application data [UDP-PMTUD] describes "Probe Packets that include Application Data" to implement "Probing using application data" of [RFC8899]. 3.1. A New PMTU Probe Packet (1-RTT packet format) (1) Probe packet format for active probing [Q-PMTUD] IP header + UDP header + Short header(QUIC header) + PING frame + PADDING frames The size of the probe packet is controlled by the number of PADDING frames. (2) Probe packet format for passive probing P.S. Kim Expires 25 April 2024 [Page 4] Internet-Draft An Alternative Path MTU Discovery for QUIC October 2023 In this drfat, a probe packet is defined newly using 1-RTT packet including actual application data as well as a PING_EXT frame as follows: IP header + UDP header + Short header(QUIC Header) + PING_EXT frame + Actual application data - PING_EXT frame (defined newly) . Frame Type Name : PING_EXT . Type Value : 0x20 . The PING_EXT frame makes the packet ack-eliciting. In addition, the PING_EXT frame indicates that the current 1-RTT packet is now discovering the best PMTU as well as transmitting actual application data. - Application data . Actual application data controls the size of the probe packet by a multiple of four bytes. The size of probe packet is changed according to PMTU candidates (=1280 + incremental where, for example, incremental can be a multiple of four as shown in [Q-PMTUD]). 3.2. Passive Probing Through the new probe packet, it is possible not only to discovery the best PMTU, but also to transmit actual application data. That is, to discover the best PMTU size and carry actual application data, the endpoint expand the payload of all UDP datagrams. (1) A simple algorithm for discovering the best PMTU As specified in RFC9000, QUIC must send QUIC packets with the smallest allowed maximum datagram size when validating a path during connection initiation or migration. Thus, the endpoint sets the probe packet initially to the smallest allowed maximum datagram size of 1280 bytes including actual application data as well as a short packet header, a PING_EXT frame. As mentioned, until the best PMTU is discovered, the size of the probe packet is changed successively according to the size of the PMTU candidate. The size of the probe packet is controlled with the size of actual application data. The size of actual application data is a multiple of four. In the active probing approach [Q-PMTUD], the endpoint uses a simple discovery algorithm that repeatedly chooses PMTU candidates to probe. Thus, seven PMTU candidate sequences are considered and each candidate sequence specifies the order in which the discovery P.S. Kim Expires 25 April 2024 [Page 5] Internet-Draft An Alternative Path MTU Discovery for QUIC October 2023 algorithm probes PMTU candidates. In addition, four metrics such as number of probed PMTU candidates, time to discover the best PMTU, network load, average PMTU estimation are defined for performance evaluations of seven sequences. However, because the process of discovering the best PMTU is carried out simultaneously in the actual application data communication, only the PMTU candidate sequence with linear upward is adopted first in this draft. The linear upward sequence selects one candidate after the other from a list of candidates in ascending order, starting with the second one (the first one was probed with the smallest allowed maximum datagram size of 1280 bytes). Other rather complex discovery algorithms that consider various PMTU candidate sequence will be dealt with in the future. Until the best PMTU is discovered, the endpoint repeats a series of probing steps. In absence of a PTB message, the discovery algorithm considers a probe for a PMTU candidate as failed, only if the probe packet of the size of the candidate were detected as lost. A probe for a PMTU candidate that fails, lets all other probes for larger candidates fail as well. Therefore, the best PMTU is the PMTU candidate that succeeded just before the failure. (2) Discovery complete and PMTU cache When the algorithm determines that it has discovered the best PMTU, the endpoint terminates the probing. Then, the endpoint sets the 1-RTT packet finally to the best datagram size using the best PMTU discovered. From now on, the 1-RTT packet does not include a PING_EXT frame. QUIC can cache the best PMTU discovered and use it for future connections to the same endpoint. (3) Other rather complex discovery algorithms Other rather complex discovery algorithms that consider various PMTU candidate sequences will be dealt with in the future. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations The same security considerations as those described in RFC7880 will apply to this document. P.S. Kim Expires 25 April 2024 [Page 6] Internet-Draft An Alternative Path MTU Discovery for QUIC October 2023 6. References [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden, Ed. "Path MTU Discovery for IP version 6", RFC 8201, DOI 10.17487/RFC8201, July 2017, . [RFC8899] Fairhurst, G., T. Jones, M. Tuxen, I. Rungeler, T. Volker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, . [UDP-PMTUD] Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-dplpmtud-10, 3 July 2023, . [RFC9000] J. Iyengar, Ed., M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [Q-PMTUD] Timo Volker, Michael Tuxen, "The search of the path MTU with QUIC", EPIQ '21: Proceedings of the 2021 Workshop on Evolution, Performance and Interoperability of QUIC, December 2021 Authors' Addresses Pyung Soo Kim Tech University of Korea Siheung, Gyeonggi South Korea Email: pskim@tukorea.ac.kr P.S. Kim Expires 25 April 2024 [Page 7]