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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

Thanks for the review Gorry.  You caught a few mistakes - one of them being quite old.

> @@ -3797,19 +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

Good point.  That's been sitting there for ages and you are the first to notice.

>  
-The considerations for processing ICMP messages in the previous section also
+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.

Yep.  Missed that in my pass.  Corrected.

>  
-The considerations for processing ICMP messages in the previous section also
+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
+
+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}}.  Endpoints could limit the content of probe
+packets to PING and PADDING frames as packets that are larger than the current

The coalescing part sort of reveals a flaw in the construction though.  It shows that the probe really uses datagrams.  At this level, I think that assuming the hack (coalescing with junk Handshake) is not involved, is OK.  Happy to take suggestions though, because this is definitely awkward.

> +DPLPMTU probe packets consume congestion window, which could delay subsequent
+transmission by an application.
+
+
+### 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.
+
+
+### 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

I don't think we use is, so thanks for drawing attention to it.  We use "connection ID" and so I have fixed this.

> -
-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
+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.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a

Yeah, this should be either.

> -used for routing.
+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.
+
+One way to construct a PMTU probe 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
+UDP datagram 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 is within the quoted portion of
+the UDP datagram, that could be used for routing.
+

Good point.  And it is either.  (Though using other junk in the packet might be better for validation, if the quoted part is indeed long enough.  One real concern with this hack is that the router might not quote enough of the packet include the the whole Source Connection ID field, especially if the Destination Connection ID - which you can't truncate either - has to be longer.)

> +({{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 PMTU probe 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
+UDP datagram 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 is within the quoted portion of
+the UDP datagram, that could be used for routing.
+
+Note:
+: The purpose of using a packet with a long header is only to ensure that the
+  quoted packet contained in the ICMP message contains a Source Connection ID

We've taken to writing these out in full.

-- 
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-419710667