Re: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.

Thank you for your changes! I think it might be useful to distinguish the "IP packet" from how we commonly use "packet", so I propose (i) simply use "PMTU probe", and (ii) saying explicitly what that refers to. I've made some suggestions through the text to this end; see what you think.

> @@ -3795,37 +3795,48 @@ later time in the connection.
 # Packet Size {#packet-size}
 
 The QUIC packet size includes the QUIC header and protected payload, but not the
-UDP or IP header.
+UDP or IP headers.
+
+QUIC depends upon a minimum IP 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.
+
+The QUIC maximum packet size is the largest size of QUIC packet that can be sent
+across a network path using a single packet. Any maximum packet size larger than
+1200 bytes can be discovered using PMTUD/DPLPMTUD.

expand/cite for PMTUD/DPLPMTUD. I don't think it's been introduced before.

>  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

Move this above to where PMTUD and DPLPMTUD are used for the first time.

> +bytes, it MUST immediately cease sending QUIC packets, except for PMTU probe
+packets, on the affected path.  An endpoint MAY terminate the connection if an

```suggestion
bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU
probes, on the affected path.  An endpoint MAY terminate the connection if an
```

> +PMTU probe packets for DPLPMTUD that use the PADDING frame implement "Probing
+using padding data", as defined in Section 4.1 of {{!DPLPMTUD}}.

```suggestion
PMTU probes for DPLPMTUD that use the PADDING frame implement "Probing
using padding data", as defined in Section 4.1 of {{!DPLPMTUD}}.
```

> +Both PMTUD and DPLPMTUD send IP packets that are larger than the current maximum
+packet size.  Aside from these PMTU probe packets, all QUIC packets SHOULD be
+sized to fit within the maximum packet size to avoid the packet being fragmented
+or dropped {{?RFC8085}}.

```suggestion
Both PMTUD and DPLPMTUD send IP packets that are larger than the current maximum
packet size.  We refer to these packets as PMTU probes. All QUIC packets that are not
in a PMTU probe SHOULD be sized to fit within the maximum packet size to avoid the
packet being fragmented or dropped {{?RFC8085}}.
```

>  apply if these messages are used by DPLPMTUD.
 
 
-### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+## Sending QUIC PMTU Probe Packets
+
+PMTU probe packets are ack-eliciting packets.

```suggestion
PMTU probes contain ack-eliciting packets.
```

>  apply if these messages are used by DPLPMTUD.
 
 
-### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+## Sending QUIC PMTU Probe Packets
+
+PMTU probe packets are ack-eliciting packets.
+
+Endpoints could limit the content of probe packets to PING and PADDING frames as

```suggestion
Endpoints could limit the content of PMTU probes to PING and PADDING frames as
```

>  apply if these messages are used by DPLPMTUD.
 
 
-### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+## Sending QUIC PMTU Probe Packets
+
+PMTU probe packets are ack-eliciting packets.
+
+Endpoints could limit the content of probe packets to PING and PADDING frames as
+packets that are larger than the current maximum packet size are more likely to
+be dropped by the network.   Loss of a QUIC packet that is carried in a PMTU
+probe packet is therefore not a reliable indication of congestion and SHOULD NOT

```suggestion
probe is therefore not a reliable indication of congestion and SHOULD NOT
```

> -packets are likely to require that the connection ID be included in PMTU 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.
-
-One way to construct a probe for the path MTU is to coalesce (see
-{{packet-coalesce}}) a Handshake packet ({{packet-handshake}}) with a short
-header packet in a single UDP datagram.  If the UDP datagram reaches the
-endpoint, the Handshake packet will be ignored, but the short header packet will
-be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the
-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to

```suggestion
PMTU probes to route any resulting ICMP messages ({{icmp-pmtud}}) back to
```

> -
-One way to construct a probe for the path MTU is to coalesce (see
-{{packet-coalesce}}) a Handshake packet ({{packet-handshake}}) with a short
-header packet in a single UDP datagram.  If the UDP datagram reaches the
-endpoint, the Handshake packet will be ignored, but the short header packet will
-be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the
-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to
+the correct endpoint.  However, only long header packets ({{long-header}})
+contain the Source Connection ID field, and long header packets are not
+decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe packet is to coalesce (see

```suggestion
One way to construct a PMTU probe is to coalesce (see
```

> -header packet in a single UDP datagram.  If the UDP datagram reaches the
-endpoint, the Handshake packet will be ignored, but the short header packet will
-be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the
-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to
+the correct endpoint.  However, only long header packets ({{long-header}})
+contain the Source Connection ID field, and long header packets are not
+decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe packet is to coalesce (see
+{{packet-coalesce}}) a packet with a long header, such as a Handshake or 0-RTT
+packet ({{long-header}}), with a short header packet in a single UDP datagram.
+If the resulting PMTU probe packet reaches the endpoint, the packet with the

```suggestion
If the resulting PMTU probe reaches the endpoint, the packet with the
```

> -be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the
-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to
+the correct endpoint.  However, only long header packets ({{long-header}})
+contain the Source Connection ID field, and long header packets are not
+decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe packet is to coalesce (see
+{{packet-coalesce}}) a packet with a long header, such as a Handshake or 0-RTT
+packet ({{long-header}}), with a short header packet in a single UDP datagram.
+If the resulting PMTU probe packet reaches the endpoint, the packet with the
+long header will be ignored, but the short header packet will be acknowledged.
+If the UDP datagram causes an ICMP message to be sent, the first part of the

```suggestion
If the PMTU probe causes an ICMP message to be sent, the first part of the
```

> -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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to
+the correct endpoint.  However, only long header packets ({{long-header}})
+contain the Source Connection ID field, and long header packets are not
+decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe packet is to coalesce (see
+{{packet-coalesce}}) a packet with a long header, such as a Handshake or 0-RTT
+packet ({{long-header}}), with a short header packet in a single UDP datagram.
+If the resulting PMTU probe packet reaches the endpoint, the packet with the
+long header will be ignored, but the short header packet will be acknowledged.
+If the UDP datagram causes an ICMP message to be sent, the first part of the
+datagram will be quoted in that message.  If the Source Connection ID field is

```suggestion
probe will be quoted in that message.  If the Source Connection ID field is
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702#pullrequestreview-421566019