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.



> @@ -2670,9 +2670,10 @@ complete.  Though the values of some fields in the packet header might be
 redundant, no fields are omitted.  The receiver of coalesced QUIC packets MUST
 individually process each QUIC packet and separately acknowledge them, as if
 they were received as the payload of different UDP datagrams.  For example, if
-decryption fails (because the keys are not available or any other reason), the
-the receiver MAY either discard or buffer the packet for later processing and
-MUST attempt to process the remaining packets.
+decryption fails (because the keys are not available, the UDP datagram is a PMTU
+probe (see {{pmtu-probes-src-cid}}), or any other reason), the the receiver MAY

It looks technically redundant, but it works to point out this use case in the _Coalescing Packets_ section. The other alternative would be to mention PMTU probes earlier (in the in the second paragraph, for example):

```suggestion
Using the Length field, a sender can coalesce multiple QUIC packets into one UDP datagram.
This can reduce the number of UDP datagrams needed to complete the cryptographic
handshake and start sending data.  This can also be used to construct PMTU probes (see
{{pmtu-probes-src-cid}}).  Receivers MUST be able to probe (see {{pmtu-probes-src-cid}}),
or any other reason), the the receiver MAY process coalesced packets.
```

I do wonder if mentioning this too early would distract from the main purpose of coalesced packets -- reducing the number of UDP datagrams during handshake.

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