draft-ietf-tsvwg-datagram-plpmtud-20.txt | draft-ietf-tsvwg-datagram-plpmtud-21.txt | |||
---|---|---|---|---|
Internet Engineering Task Force G. Fairhurst | Internet Engineering Task Force G. Fairhurst | |||
Internet-Draft T. Jones | Internet-Draft T. Jones | |||
Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen | Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen | |||
approved) M. Tuexen | approved) M. Tuexen | |||
Intended status: Standards Track I. Ruengeler | Intended status: Standards Track I. Ruengeler | |||
Expires: 8 November 2020 T. Voelker | Expires: 13 November 2020 T. Voelker | |||
Muenster University of Applied Sciences | Muenster University of Applied Sciences | |||
7 May 2020 | 12 May 2020 | |||
Packetization Layer Path MTU Discovery for Datagram Transports | Packetization Layer Path MTU Discovery for Datagram Transports | |||
draft-ietf-tsvwg-datagram-plpmtud-20 | draft-ietf-tsvwg-datagram-plpmtud-21 | |||
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 packet | detect and reduce the message size when a sender encounters a packet | |||
skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
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 8 November 2020. | This Internet-Draft will expire on 13 November 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 4, line 4 ¶ | skipping to change at page 4, line 4 ¶ | |||
6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 37 | 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 37 | |||
6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 37 | 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 37 | |||
6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 37 | 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 37 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 39 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 41 | 10.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 42 | Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 42 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
1. Introduction | 1. Introduction | |||
The IETF has specified datagram transport using UDP, SCTP, and DCCP, | The IETF has specified datagram transport using UDP, SCTP, and DCCP, | |||
as well as protocols layered on top of these transports (e.g., SCTP/ | as well as protocols layered on top of these transports (e.g., SCTP/ | |||
UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP | UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP | |||
network layer. This document describes a robust method for Path MTU | network layer. This document describes a robust method for Path MTU | |||
Discovery (PMTUD) that can be used with these transport protocols (or | Discovery (PMTUD) that can be used with these transport protocols (or | |||
the applications that use their transport service) to discover an | the applications that use their transport service) to discover an | |||
appropriate size of packet to use across an Internet path. | appropriate size of packet to use across an Internet path. | |||
skipping to change at page 37, line 6 ¶ | skipping to change at page 37, line 6 ¶ | |||
in termination of the connection if an alternative path cannot be | in termination of the connection if an alternative path cannot be | |||
found [I-D.ietf-quic-transport]. | found [I-D.ietf-quic-transport]. | |||
6.3.1. Initial Connectivity | 6.3.1. Initial Connectivity | |||
The base protocol is specified in [I-D.ietf-quic-transport]. This | The base protocol is specified in [I-D.ietf-quic-transport]. This | |||
provides an acknowledged PL. A sender can therefore enter the BASE | provides an acknowledged PL. A sender can therefore enter the BASE | |||
state as soon as connectivity has been confirmed. | state as soon as connectivity has been confirmed. | |||
QUIC provides an acknowledged PL, a sender can therefore enter the | QUIC provides an acknowledged PL, a sender can therefore enter the | |||
BASE state as soon as connectivity has been confirmed. | BASE state as soon as the connection handshake has been completed and | |||
the endpoint has an 1-RTT key established. | ||||
6.3.2. Sending QUIC Probe Packets | 6.3.2. Sending QUIC Probe Packets | |||
Probe packets consist of a QUIC Header and a payload containing a | Probe packets consist of a QUIC Header and a payload containing a | |||
PING Frame and multiple PADDING Frames. A PADDING Frame is | PING Frame and multiple PADDING Frames. A PADDING Frame is | |||
represented by a single octet (0x00). Several PADDING Frames are | represented by a single octet (0x00). Several PADDING Frames are | |||
used together to control the length of the probe packet. The PING | used together to control the length of the probe packet. The PING | |||
Frame is used to trigger generation of an acknowledgement. | Frame is used to trigger generation of an acknowledgement. | |||
The current specification of QUIC sets the following: | The current specification of QUIC sets the following: | |||
skipping to change at page 46, line 48 ¶ | skipping to change at page 46, line 48 ¶ | |||
Murray S. Kucherawy. | Murray S. Kucherawy. | |||
Working group draft -20: | Working group draft -20: | |||
* Address nits and comments from IESG | * Address nits and comments from IESG | |||
* Refer to BCP 145 rather than RFC 8085 in most places. | * Refer to BCP 145 rather than RFC 8085 in most places. | |||
* Update probing method text for SCTP and QUIC. | * Update probing method text for SCTP and QUIC. | |||
Working group draft -21: | ||||
* Update QUIC text for skipping into BASE state. | ||||
Authors' Addresses | Authors' Addresses | |||
Godred Fairhurst | Godred Fairhurst | |||
University of Aberdeen | University of Aberdeen | |||
School of Engineering | School of Engineering | |||
Fraser Noble Building | Fraser Noble Building | |||
Aberdeen | Aberdeen | |||
AB24 3UE | AB24 3UE | |||
United Kingdom | United Kingdom | |||
End of changes. 7 change blocks. | ||||
6 lines changed or deleted | 11 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/ |