Packetization Layer Path MTU Discovery for Datagram Transports
draft-fairhurst-tsvwg-datagram-plpmtud-00.txt

Abstract

This document describes a robust method for Path MTU Discovery (PMTUD) for datagram packetization layers. It allows these layers to probe an Internet path with progressively larger packets to determine a maximum packet size This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6. The document provides functionally for datagram transports that is equivalent to the packetization layer PMTUD specification for TCP, specified in RFC4821.

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 http://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 January 4, 2018.

Copyright Notice

Copyright (c) 2017 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Requirements
• 3.1. PMTU Probing Methods
• 4. Specification of PMTUD for Packetization Layers
• 5. Specification or Protocol Specific Methods
• 5.1. UDP and UDP-Lite
• 5.1.1. UDP Options
• 5.2. SCTP
• 5.2.1. SCTP/IP4 and SCTP/IPv6
• 5.2.1.1. Probing
• 5.2.1.2. PTB Message Handling
• 5.2.2. SCTP/UDP
• 5.2.2.1. Probing
• 5.2.2.2. PTB Message Handling
• 5.2.3. SCTP/DTLS
• 5.2.3.1. Probing
• 5.2.3.2. PTB Message Handling
• 5.3. DCCP
• 5.3.1. DCCP/UDP
• 5.4. QUIC
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Revision Notes
• Authors' Addresses

1. Introduction

The IETF has specified datagram transport using UDP, SCTP, SCTP/UDP, DCCP, and DCCP/UDP as well as upper layer protocols layered on top of these transports.

Classical Path MTU Discovery (PMTUD) can be used with any transport that is able to process ICMP Packet Too Big (PTB) messages (e.g., [RFC1191][I-D.ietf-6man-rfc1981bis]). It adjusts the Effective Path MTU (PMTU), based on reception of ICMP PTB messages to decrease the PMTU when this is larger than the value supported along a path, and a method that increases the packet size in attempt to discover an increase in the supported PMTU. However, ICMP messages are being increasingly filtered by middleboxes (including Firewalls) [RFC4890]. Classical PMTUD is therefore subject to protocol failures (e.g., traffic using a packet size larger than the actual supported PMTU is blackholed when ICMP PTB messages are not delivered for some reason [RFC2923]).

Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not rely upon network or transport support for ICMP messages and is therefore considered more robust than Classical PMTUD. This has become the preferred approach for TCP traffic. The general strategy is for the Packetization Layer to find an appropriate PMTU by sending probe packets along the path with a progressively larger packet size. If a probe packet is successfully delivered (as determined by the PL), then the effective Path MTU is raised to the probe size. PLPMTUD introduces flexibility in the implementation of classical PMTUD. It can be configured to only perform ICMP black hole recovery to increase the robustness of classical PMTUD, or at the other extreme, all ICMP processing can be disabled and PLPMTUD can completely replace classical Path MTU Discovery. Using PLPMTUD, classical Path MTU Discovery can also be modified to include additional consistency checks without increasing the risk of connection hangs due to spurious failures of the additional checks.

The UDP-Guidelines [RFC8085] state "an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD)", but does not provide a mechanism for discovering the largest size of unfragmented datagram than can be used on a path. This specification describes how these datagram transports perform PLPMTUD. This mechanism has not currently been specified for UDP, while Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing method for SCTP.

Section Section 4 of this document presents a set of algorithms for datagram protocols to discover the maximum transmission unit possible on a path at the packetization layer. The methods described rely on features of transport protocols and apply to transport protocols over IPv4 and IPv6. They do not require cooperation from the lower layers (except that they are consistent about which packet sizes are acceptable) or from peers.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Other terminology is directly copied from [RFC4821], the EMTU definitions are from [RFC1122].

Address:

An IP Layer identifier for an interface or a set of interfaces.

Classical Path MTU Discovery:

The process described in [RFC1191] and [I-D.ietf-6man-rfc1981bis], in which nodes rely on ICMP PTB messages to learn the MTU of a path.

Datagram:

A transport-layer protocol data unit, transmitted in the payload of an IP packet.

Effective PMTU:

The current estimated value for PMTU used by a Packetization Layer.

EMTU_S:

The Effective MTU for sending (EMTU_S) is designated in [RFC1122] as " the maximum IP datagram size that may be sent, for a particular combination of IP source and destination addresses..."

EMTU_R:

The Effective MTU for receiving (EMTU_R) is designated in [RFC1122] as "the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive")"

Interface:

A node's attachment to a link.

Link:

A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernet LANs and Internet (or higher) layer and tunnels.

Link MTU:

Maximum Transmission Unit, the size in bytes of the largest IP packet, including the IP header and payload, that can be transmitted on a link or path. Note that this could more properly be called the IP MTU, to be consistent with how other standards organizations use the acronym MTU. This includes the IP header, but excludes link layer headers and other framing that is not part of IP or the IP payload. Be aware that other standards organizations generally define link MTU to include the link layer headers.

Packet:

An IP header plus the IP payload.

Packetization Layer:

The layer of the network stack that places data into packets and performs transport protocol functions.

Path:

The set of links traversed by a packet between a source node and a destination node.

Path MTU, or PMTU:

The minimum link MTU of all the links in a path between a source node and a destination node.

PLPMTUD:

Packetization Layer Path MTU Discovery, the method described in this document, which is an extension to classical PMTU Discovery.

3. Requirements

All of the requirements in [RFC4821] apply. There are also a number of design constraints imposed by datagram transports. TCP PLPMTUD has been defined using standard TCP protocol mechanism. Unlike TCP, some datagram transports require additional or optional mechanisms to implement PLPMTUD. This can place constraints on deployment when only one end supports the new method.

There are eight functions that any Datagram PLPMTUD mechanisms needs to perform:

1. PMTU parameters: A method MUST utilize information about the maximum size of packet that can be transmitted by the sender on the local link (Link MTU) and MAY utilize similar information about the receiver link, when this is supplied (note this may be less than EMTU_R). Some applications also have a maximum transport protocol data unit (PDU) size, in which case there may be no benefit from probing for a size larger than this (unless a transport offers benefit from multiplexing multiple applications PDUs into the same datagram.)
2. Effective PMTU: A datagram applications MUST be able to choose the size of datagrams sent to the network, based on the effective MTU. This value is managed by the PMTUD method, and sets the maximum size of datagram that an application can send. The effective PMTU (specified in Section 1 of [RFC1191]) is equivalent to the EMTU_S (specified in [RFC1122]).
3. Processing ICMP PTB messages: A method MAY optionally utilize ICMP PTB information from the network layer to help identify when a path does not support a message size (i.e. reduce the effective PMTU). The validity of PTB messages SHOULD to be verified before they are used to update the path MTU discovery information [I-D.ietf-6man-rfc1981bis].
4. Path validation: An endpoint needs to confirm the current path support the current effective datagram size, without relying solely on ICMP PTB messages. In this respect, the mechanism MUST be robust to path changes that could have occurred since the path characteristics were last confirmed. A method MUST also be robust to the possibility that a flow encounters reordering, or has the traffic divided over more than one network path.
5. When to probe: An endpoint method SHOULD determine whether the path capacity has increased since it last measured the path characteristics. The endpoint needs a method to determine when a probe datagram is transmitted, and it MUST cache the values between probes. This method needs to consider the disruption that may be incurred by an unsuccessful probe - both upon the flow that incurs a probe loss, and other flows that experience the effect of additional probe traffic.
6. Reception feedback: An endpoint MUST provide a feedback method to indicate when a probe message has been received by the remote endpoint. If the data in the probe message needs to be sent reliably, the transport needs to arrange retransmission/repair of any resulting loss. The method also needs to be robust in the case where probe messages are lost due to other reasons than a PMTU exceeded (e.g., link transmission error, congestion). The isolated loss of a probe packet (with or without an ICMP Packet Too Big message) is treated as an indication of an MTU limit, and not as a congestion indicator. In this case alone, the Packetization Protocol is permitted to retransmit any missing data without adjusting the congestion window.
7. Shared state: 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 RFC821) SHOULD be notified to make use of the new MTU and make the required congestion control adjustments". Such methods need to robust to the wide variety of underlying network forwarding behaviours. Considerations about caching have been noted [I-D.ietf-6man-rfc1981bis].
8. Not interfere with congestion control: If the transport protocol implements a congestion control, the loss of a probe packet SHOULD NOT affect the congestion control if the probe packets are not contain user data.

3.1. PMTU Probing Methods

Many datagram protocols provide mechanisms to distinguish in-band data from padding. In contrast, TCP to generate probes by appropriately segmenting data. There are three ways of creating probes, using application data, using application data and padding and padding only:

• A probe datagram can contain only padding (these probes consume capacity, but do not require retransmission of user data) and control data.
• A probe datagram can contain user data that is combined with control data and padding to inflate the length of the datagram to the size required for the probe. A loss of this probe could require retransmission/repair of the data if required by the application/transport.
• A probe datagram can contain data supplied by an application that matches the size required for the probe. This requires a method to request the application to issue a packet of the desired probe size. A loss of this probe could require retransmission/repair of the data if required by the application/transport.

Three approaches are possible for providing datagram reliability:

1. A transport/application does not require a probe datagram to be retransmitted in the event of the loss of a probe.
2. A transport/application requires retransmission of the data part of a probe in the event of a loss.
3. A transport/application is allowed to replicate the data sent in a probe in a packet (or packets) less than the size current effective PMTU to reduce the need for retransmission.

4. Specification of PMTUD for Packetization Layers

<< Fill in a generic algorithm based on sending probe packets, receiving success indications and possibly handling PTB messages. These three operations are protocol specific and are described in Section 5 for various protocols. >>

5. Specification or Protocol Specific Methods

<< In future revisions of this document, this section may be divided into PMTUD and PLPMTUD methods >>

5.1. UDP and UDP-Lite

UDP and UDP-LIte [RFC3828] do not provide a method that allows padding to be added to a datagram.

<< This section will be completed in a future revision of this ID >>

5.1.1. UDP Options

UDP places additional design requirements on an application that wishes to use PLPMTUD. UDP Options permits padding to be added to UDP datagrams [I-D.ietf-tsvwg-udp-options], and can be used to provide reception feedback. Therefore, UDP-Options can be used to assist UDP applications by supplying the additional functionality and using this to provide a Datagram PMTUD service similar to that offered by other transports.

<< This section will be completed in a future revision of this ID >>

5.2. SCTP

Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing method for SCTP. It recommends use of the PAD chunk, defined in [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build a probe packet. This allows to perform probing without affecting the transfer of user messages and without interfering with congestion control. Therefore it is preferred to the use of DATA chunks (with padding as required) to serve as path probes.

<< We might define a parameter contained in the INIT and INIT ACK chunk to indicated the MTU to the peer. However, multihoming makes this a bit complex, so it might not be worth doing. >>

5.2.1. SCTP/IP4 and SCTP/IPv6

The base protocol is specified in [RFC4960].

5.2.1.1. Probing

Probe packets consist of an SCTP common header followed by a HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control the length of the probe packet. The HEARTBEAT chunk is used to trigger the sending of a HEARTBEAT ACK chunk. The reception of the HEARTBEAT ACK chunk signals the successful probing.

5.2.1.2. PTB Message Handling

Normal ICMP verification MUST be performed as specified in Appendix C of [RFC4960]. This requires that the first 8 bytes of the SCTP common header are contained in the ICMP packet, which is normally fulfilled by ICMPv4 and ICMPv6.

5.2.2. SCTP/UDP

The UDP encapsulation of SCTP is specified in [RFC6951].

5.2.2.1. Probing

The probing can be performed as specified in Section 5.2.1.1.

5.2.2.2. PTB Message Handling

Normal ICMP verification has to be performed as specified in [RFC4960]. However, this might not be possible for ICMPv4, since it is not guaranteed that the ICMP packet contains the first 8 bytes of the SCTP common header. ICMPv6 packets should contain enough information to perform the required verification.

5.2.3. SCTP/DTLS

The DTLS encapsulation of SCTP is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. It is used for data channels in WebRTC implementations.

5.2.3.1. Probing

The probing can be done as specified in Section 5.2.1.1.

5.2.3.2. PTB Message Handling

Normal ICMP verification can not be performed as specified in [RFC4960], since even if the ICMP contains enough information, the reflected SCTP common header would be encrypted. Therefore it is not possible to process ICMP PTB messages.

5.3. DCCP

DCCP [RFC4340] implementations are required to support classical PMTUD and states that a DCCP sender "MUST maintain the maximum packet size (MPS) allowed for each active DCCP session" and also defines "current congestion control mechanism (CCMPS), the maximum packet size supported by the path's links". It recommends use of PMTUD, and suggests use of DCCP-Sync packets as path probes, because they do not risk application data loss. It does not currently specify the use of PLPMTUD methods that could work independently of the ability to utilise ICMP PTB messages.

<< This section will be completed in a future revision of this ID >>

5.3.1. DCCP/UDP

DCCP/UDP is a UDP-based transport that permits padding to be added to datagrams, and can provide reception feedback.

<< This section will be completed in a future revision of this ID >>

5.4. QUIC

QUIC is a UDP-based transport that provides reception feedback [draft-ietf-quic-transport].

<< This section will be completed in a future revision of this ID >>

6. Acknowledgements

This work was partially funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s).

7. IANA Considerations

This memo includes no request to IANA.

If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

8. Security Considerations

The security considerations for the use of UDP and SCTP are provided in the references RFCs. Security guidance for applications using UDP is provided in the UDP-Guidelines [RFC8085].

ICMP PTB messages could potentially be used to cause a node to inappropriately reduce the PMTU. A node supporting PLPMTUD SHOULD appropriately validate the payload of ICMP PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to a datagram actually sent by the path layer.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Revision Notes

Note to RFC-Editor: please remove this entire section prior to publication.

Individual draft -00:

• This is the first version. Comments and corrections are welcome directly to the authors or via the IETF TSVWG working group mailing list.

Authors' Addresses