Reflow

draft-ietf-quic-transport.md

@@ -3797,25 +3797,24 @@ later time in the connection.
 The QUIC packet size includes the QUIC header and protected payload, but not the
 UDP or IP header.
 
-QUIC depends upon a minimum packet size of at least 1280 bytes.
-This is the IPv6 minimum size
-{{?RFC8200}} and is also supported by most modern IPv4 networks.
-Assuming the minimum IP header size, this results in a
-QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. 
+QUIC depends upon a minimum packet size of at least 1280 bytes.  This is the
+IPv6 minimum size {{?RFC8200}} and is also supported by most modern IPv4
+networks.  Assuming the minimum IP header size, this results in a QUIC maximum
+packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4.
 
 A client MUST expand the payload of all UDP datagrams carrying Initial packets
 to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
 coalescing the Initial packet; see {{packet-coalesce}}.  Sending a UDP datagram
 of this size ensures that the network path from the client to the server
-supports a reasonable Path Maximum Transmission Unit (PMTU).  Padding datagrams also
-helps reduce the amplitude of amplification attacks caused by server responses
-toward an unverified client address; see {{address-validation}}.
+supports a reasonable Path Maximum Transmission Unit (PMTU).  Padding datagrams
+also helps reduce the amplitude of amplification attacks caused by server
+responses toward an unverified client address; see {{address-validation}}.
 
 Enforcement of the max_udp_payload_size transport parameter
-({{transport-parameter-definitions}}) might act as an additional limit on
-the maximum packet size. A sender can avoid exceeding this limit, once the value is known.
-However, prior to learning the value of the transport parameter, endpoints risk
-datagrams being lost if they send packets larger than 1200 bytes.
+({{transport-parameter-definitions}}) might act as an additional limit on the
+maximum packet size. A sender can avoid exceeding this limit, once the value is
+known.  However, prior to learning the value of the transport parameter,
+endpoints risk datagrams being lost if they send packets larger than 1200 bytes.
 
 Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 believes that the network path and peer both support the size that it chooses.
@@ -3844,37 +3843,35 @@ referred to as the endpoint's maximum packet size.
 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
 ({{!DPLPMTUD=I-D.ietf-tsvwg-datagram-plpmtud}}) or implement Path MTU Discovery
 (PMTUD) {{!RFC1191}} {{!RFC8201}} to determine whether the path to a destination
-will support a desired message size without fragmentation.
-In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
-larger than the minimum QUIC packet size. 
+will support a desired message size without fragmentation.  In the absence of
+these mechanisms, QUIC endpoints SHOULD NOT send IP packets
+larger than the minimum QUIC packet size.
 
-All QUIC
-packets other than PMTUD/DPLPMTUD probe packets SHOULD be sized to fit within the
-maximum packet size to avoid the packet being fragmented or dropped
+All QUIC packets other than PMTUD/DPLPMTUD probe packets SHOULD be sized to fit
+within the maximum packet size to avoid the packet being fragmented or dropped
 {{?RFC8085}}.
 
 If a QUIC endpoint determines that the PMTU between any pair of local and remote
-IP addresses has fallen below the smallest allowed maximum packet size, it MUST immediately 
-cease sending QUIC packets, except for
-PMTUD or DPLPMTUD probe packets, on the affected path.  An endpoint MAY terminate the
-connection if an alternative path cannot be found.
+IP addresses has fallen below the smallest allowed maximum packet size, it MUST
+immediately cease sending QUIC packets, except for PMTUD or DPLPMTUD probe
+packets, on the affected path.  An endpoint MAY terminate the connection if an
+alternative path cannot be found.
 
 Each pair of local and remote addresses could have a different PMTU.  QUIC
 implementations that implement any kind of PMTU discovery therefore SHOULD
 maintain a maximum packet size for each combination of local and remote IP
 addresses.
 
-A QUIC
-implementation MAY be more conservative in computing the maximum packet
+A QUIC implementation MAY be more conservative in computing the maximum packet
 size to allow for unknown tunnel overheads or IP header options/extensions.
 
 
 ### Handling of ICMP Messages by PMTUD {#icmp-pmtud}
 
-PMTUD {{!RFC1191}} {{!RFC8201}} relies on reception of ICMP messages
-(e.g., IPv6 Packet Too Big messages) that indicate when a packet is dropped
-because it is larger than the local router MTU. DPLPMTUD can also optionally use
-these messages.  This use of ICMP messages is potentially vulnerable to off-path
+PMTUD {{!RFC1191}} {{!RFC8201}} relies on reception of ICMP messages (e.g., IPv6
+Packet Too Big messages) that indicate when a packet is dropped because it is
+larger than the local router MTU. DPLPMTUD can also optionally use these
+messages.  This use of ICMP messages is potentially vulnerable to off-path
 attacks that successfully guess the addresses used on the path and reduce the
 PMTU to a bandwidth-inefficient value.
 
@@ -3887,19 +3884,21 @@ exceeding the minimum MTU for the IP version.  The size of the quoted packet can
 actually be smaller, or the information unintelligible, as described in Section
 1.1 of {{!DPLPMTUD}}.
 
-QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect from off-path injection
-as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}. This validation
-SHOULD use the quoted packet supplied in the payload of an ICMP message to
-associate the message with a corresponding transport connection (see Section 4.6.1 of {{!DPLPMTUD}}).
-ICMP message validation MUST include matching IP addresses and UDP ports
-{{!RFC8085}} and, when possible, connection IDs to an active QUIC session.
-The endpoint SHOULD ignore all ICMP messages that fail validation.
+QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect from
+off-path injection as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}.
+This validation SHOULD use the quoted packet supplied in the payload of an ICMP
+message to associate the message with a corresponding transport connection (see
+Section 4.6.1 of {{!DPLPMTUD}}).  ICMP message validation MUST include matching
+IP addresses and UDP ports {{!RFC8085}} and, when possible, connection IDs to an
+active QUIC session.  The endpoint SHOULD ignore all ICMP messages that fail
+validation.
 
 An endpoint MUST NOT increase PMTU based on ICMP messages; see Section 3, clause
 6 of {{!DPLPMTUD}}.  Any reduction in the QUIC maximum packet size in response
 to ICMP messages MAY be provisional until QUIC's loss detection algorithm
 determines that the quoted packet has actually been lost.
 
+
 ### PMTUD Probes with Handshake packets
 
 One way to construct a PMTU probe is to coalesce (see
@@ -3911,67 +3910,69 @@ first part of the datagram will be quoted in that message.  If the source
 connection ID is within the quoted portion of the UDP datagram, that could be
 used for routing.
 
+
 ## Datagram Packetization Layer PMTU Discovery
 
-When implementing the algorithm in Section 5 of {{!DPLPMTUD}}, the
-initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC
-packet size. The MIN_PLPMTU is the same as the BASE_PMTU.
+When implementing the algorithm in Section 5 of {{!DPLPMTUD}}, the initial value
+of BASE_PMTU SHOULD be consistent with the minimum QUIC packet size. The
+MIN_PLPMTU is the same as the BASE_PMTU.
 
-QUIC endpoints implementing DPLPMTUD maintain a maximum packet size 
-(DPLPMTUD MPS) for each combination of local and remote IP
-addresses.
+QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD
+MPS) for each combination of local and remote IP addresses.
+
+If a QUIC endpoint determines that the PLPMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the minimum QUIC
+packet size (BASE_PLPMTU), it MUST immediately cease sending QUIC packets,
+except for DPLPMTUD probe packets, on the affected path. An endpoint MAY
+terminate the connection if an alternative path cannot be found.
 
-If a QUIC endpoint determines that the PLPMTU between any pair of local
-and remote IP addresses has fallen below the size needed to support
-the minimum QUIC packet size (BASE_PLPMTU), it MUST immediately cease
-sending QUIC packets, except for DPLPMTUD probe packets, on the affected
-path. An endpoint MAY terminate the connection if an alternative
-path cannot be found.
 
-###  DPLPMTUD and Initial Connectivity
+### DPLPMTUD and Initial Connectivity
 
-From the perspective of DPLPMTUD, QUIC transport is an 
-acknowledged packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE
-state when the QUIC connection handshake has been completed and
-the endpoint has established a 1-RTT key.
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.
 
-###  Sending QUIC DPLPMTUD Probe Packets
+
+### Sending QUIC DPLPMTUD Probe Packets
 
 DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
 PADDING frame therefore implement "Probing using padding data", as defined in
-Section 4.1 of {{!DPLPMTUD}}.
-These can be generated without affecting the transfer of other QUIC frames.
-The PING Frame is used to trigger generation of an acknowledgement.
-Multiple PADDING Frames are used together to control the length of the probe packet.  
-These frames might not be retransmitted if a probe packet containing
-them is lost.  The frames consume congestion window,
-which could delay subsequent transmission by an application.
+Section 4.1 of {{!DPLPMTUD}}.  These can be generated without affecting the
+transfer of other QUIC frames.  The PING Frame is used to trigger generation of
+an acknowledgement.  Multiple PADDING Frames are used together to control the
+length of the probe packet.  These frames might not be retransmitted if a probe
+packet containing them is lost.  The frames consume congestion window, which
+could delay subsequent transmission by an application.
+
 
-###  Validating the QUIC Path with DPLPMTUD
+### Validating the QUIC Path with DPLPMTUD
+
+QUIC provides an acknowledged PL, therefore a sender does not implement the
+DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
 
-QUIC provides an acknowledged PL, therefore a sender does not
-implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
 
 ###  Handling of ICMP Messages by DPLPMTUD
 
-An endpoint using DPLPMTUD requires the validation of any received PTB message 
-before using the PTB information, as defined in section 4.6 of {{!DPLPMTUD}}.
-In addition to UDP Port
-validation, QUIC validates an ICMP message by using other PL
-information (e.g., validation of connection identifiers (CIDs) in the
-quoted packet of any received ICMP message). 
+An endpoint using DPLPMTUD requires the validation of any received PTB message
+before using the PTB information, as defined in Section 4.6 of {{!DPLPMTUD}}.
+In addition to UDP Port validation, QUIC validates an ICMP message by using
+other PL information (e.g., validation of connection identifiers (CIDs) in the
+quoted packet of any received ICMP message).
 
 The considerations for processing ICMP messages described in {{icmp-pmtud}} also
 apply if these messages are used by DPLPMTUD.
 
+
 ## PMTUD/DPLPMTUD Probes Containing Source Connection ID {#pmtu-probes-src-cid}
 
 Endpoints that rely on the destination connection ID for routing incoming QUIC
-packets are likely to require that the connection ID be included in PMTUD/DPLPMTUD probe
-packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to the
-correct endpoint.  However, only long header packets ({{long-header}}) contain
-source connection IDs, and long header packets are not decrypted or acknowledged
-by the peer once the handshake is complete.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
 
 
 # Versions {#versions}