Re: [quicwg/base-drafts] Describe PMTU probing that includes source connection ID for routing … (#2402)

[Igor Lubashev <[e-mail]>]

igorlord commented on this pull request.



> @@ -3274,6 +3274,22 @@ The considerations for processing ICMP messages in the previous section also
 apply if these messages are used by DPLPMTUD.
 
 
+### PMTU Probes Containing Source Connection ID
+
+Endpoints that rely on the destination connection ID for routing QUIC packets
+are likely to require that connection ID included in PMTU probe packets in order
+to route resulting ICMP messages ({{icmp-pmtud}}) back to the correct endpoints.
+
+Only long header packets ({{long-header}}) contain source connection IDs, but
+long header packets will not be acknowledged once the connection has been
+established.  One way to construct a PMTU probe is to coalesce (see
+{{packet-coalesce}}) a Handshake packet ({{packet-handshake}}) with a short

> it might be better to suggest use of any coalescible long header packet rather than specifically suggesting the use of a Handshake packet.

Here are the long header packet types:

1. Initial.
I hesitate to use _initial_, because it is plaintext (no decryption failures) and has an ability to actually create new connections due to unfortunate delays / mis-routing.  Load balancer infrastructure may treat them differently from other packets.

2. 0-rtt.
These are supposed to be client-to-server only.  Having servers send them may be a bit unexpected.

3.  Handshake.
That's what I picked.

4.  Retry.
This does not have length, so it is not eligible.

That leaves only Handshake as the best candidate.  And one type is enough.

-- 
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/2402#discussion_r253654693