Change:
The considerations for processing ICMP messages in the previous section also apply if these messages are used by DPLPMTUD. <ins> 14.3.1. Endpoints that rely on the destination connection ID for routing QUIC 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 PMTU probe 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 elicits an ICMP message, that message will likely contain the source connection ID within the quoted portion of the UDP datagram. </ins> 15. QUIC versions are identified using a 32-bit unsigned number.

Discussion:
Describe PMTU probing that includes source connection ID for routing ICMP back the correct endpoints. This should
Sorry, but this sounds like a huge hack - coalescing with unused handshake packets. It also sounds like it is at risk of being ignored. I'd rather see a specific permission for a probe packet with a longer header as the only long header permissible throughout the connection, and possibly require it to not be coalesced with anything.
I tend to agree. Yet, the described method is what was determined at Kista to be the best way, and this was reconfirmed in Tokyo. I am happy to rewrite using a special long header packet type, if the wg decides to pivot toward that. At the end of the day, having something that works is what matters the most.
NAME My understanding is that the approach is perfectly fine; see what a receiver is supposed to do in section 12.2. I am opposed to introducing a special type of long header packet just for this purpose; that would be an unnecessary complexity. OTOH I agree that servers might be interesting in greasing this feature (by coalescing every 1-RTT packet that the server sends with an invalid long header packet, for small portion of the connections it handles).
NAME Coalescing something with handshake packets is no different than not coalescing. You are sending long header packets post 1-RTT. Disregarding the actual text, I still find it inelegant and error prone.
Another point, which is important at least to me: The entire idea about not having long headers post 1-RTT, and to make a note of it, is to allow implementations to focus on short packets only for the reminder of the connection, and dropping all context about separate number spaces etc.. If that stops being the case, all the bootrapping mess comes back to haunt you. I'd switch to different packet processor post handshake so there is no ACK special handling etc. If you have a dedicated allowance for a probe packet, that is much easier to deal with because you know the context is the same is for the short headers.
NAME No special handling is necessary, aside from splitting the coalesced packets. The design does not require the receiver to actually handle the long header packet.

Simply dropping it is fine, as long as the receiver processes the short header packet that is being coalesced with the long header packet. I understand the fact that you want to have an optimized path for short header packets. That's fine. OTOH, the receiver needs to handle a coalesced datagram that carries various types of long header packets and a 1-RTT packet, at least during the handshake. This is true even if you do not have a corresponding key (e.g. you need to "drop" a 0-RTT packet in a coalesced datagram even when you do not not have the 0-RTT key). Considering that, I am not sure if it a good idea to disable the logic to split coalesced datagram into multiple packets when dropping the Handshake key. Isn't it an additional complexity to disable the logic upon the completion of the handshake? FWIW, the specification currently states: Every QUIC packet that is coalesced into a single UDP datagram is separate and 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. ().
To an extend yes, but if you do care about performance, it can be a simplification: You need the core functionality regardless, so it is mostly function calls to logic that must exist either way. And, it allows you to be more lazy performance wise when dealing with the complexities of the handshake where crypto overhead and low packet count does not make optimisations worthwhile. This means you can shift that focus to short packets. This gets into biblical citations, but ... >Every QUIC packet that is coalesced into a single UDP datagram is separate and complete. but it also says that you cannot have multiple connections, and you cannot have long headers post 1-RTT.

Technically you can coalesce a packet "sent" before the packet being coalesced, but if you have seen a short header, you can reasonably assume that any long headers are of no interest and therefore drop processing of that datagram ASAP.
Some background that might illustrate why this is feasible: You can attach a state machine to the connection. Each state has function that is called on new input. Once the state enters short packet state, it can a be different function from the handshake related state handlers. So you just look up the CID, and call a function. The same goes for draining etc.
The coalescing logic requires you to skip long header packets after the handshake and process the coalesced packets in the UDP datagram. I.e. you need to wrap this is a loop. In Tokyo we decided that you can limit the number of times you will go through this loop per UDP datagram, if you want. (I think we said that the limit can be as low as 4.)
That's correct. You cannot coalesce QUIC packets belonging to multiple connections into the same UDP datagram. This is not changed. It is also correct that a long-header packet past the completion of the handshake is not valid. So you need to do with that long-header QUIC packet what you would do with invalid packets -- drop it. (That's why the text says that such packets will not elicit an acknowledgement.) But then you should keep processing coalesced QUIC packets arriving in the same datagram, per text of the spec.
I do not disagree, I'm just saying that, except for this probing edge case, you really have no motivation to keep processing such packets at that point in time. Anybody wanting piggyback other payload on meaningful short header content is probably playing some games. But you can't because of this special case.
But, if you actually drop the longer header and proceed to the short header probe, you loose your source ID, so for it to work, you need to go against the current spec and process long headers post 1-RTT. Furthermore, you go against an important design principle of keeping seperate packets separate. How can you be sure the preceding long packet contains the intended source ID, under strict interpretation of the protocol?

Instead I'd be much simpler to include the source id in the probe packet somehow.
Umm, if you don't have the handshake keys anymore, how do verify the long packet. And if you don't, how can you trust that someone didn't throw in some other source id (not sure that would be an efficient attack, but still).
Better, you cannot send Handshake packets at all when you no longer have the keys, and if you could, they would be open to MiTM because they keys aren't really that secure since the handshake as already been accepted and therefore cannot fail. So that leaves sending handshake packets with 1-RTT keys, and I couldn't really find where this is prohibited, but I believe the idea is that each packet type identifies an encryption level.
The long header packet is a Handshake packet because the first octet identifies it as such. It will not decrypt and is not meant to be decrypted (only short header packets are valid at this point in the connection). I guess a little more text is needed to make this point clear.
NAME Regarding optimization, an endpoint would rarely send PMTU probes. Therefore, processing of the probe going into a slow path is not an issue. Almost all the packet that the receiver receives would be short header packets.
NAME the problem is not slow pathing rare packets, but fast pathing approved connections - so they never parse anything but short headers or fail. However, if a probe uses a new CID this is indeed not a concern because the CID would not hit the fast path in the first place.
The probe is a part of the connection. Otherwise it will not elicit an ACK of the coalesced short packet. I am a bit confused that we are discussing the cost of a single if statement.
But it will use a dedicated connection ID. Yes, but it still impacts the design because the first thing I would do would be to look up bytes 1-4 in a hash table and call a handler function that has no context for handshake. So it will now have to add an indirection and process packets it does not understand. It can't be the same logic as the one that handles handshakes, because it would start by verifying the packet.

Or that initial lookup would would have to first check the packet type and go slow path, but the context must be looked up by ID, and the general slow path expects context, or it will drop packets. But you can't do that here, because there is no context. So you have to special handle that. So performance-wise it would be survivable, just pretty ugly.
I also don't understand exactly the purpose of the source id: Is it a) for the ending endpoint to make sense of ICMP, or b) do you expect ICMP to be routed based on the QUIC headers? If it is a), why would you not want the source ID to be authenticated? I could see some interesting attacks sending bogus ICMP packets to manipulate the connection. For example by network operators that want to bandwidth limit QUIC packets. That is, if enough of the copy survives to have anything that can be authenticated.
Can we PLEASE have these discussions on the issue and not the PR?
Thanks for the PR, NAME
They don't have a length field, so the only place they could go is at the end of a packet. As the spec currently stands, it's valid to send a packet like this. There's little value in doing that. Do we want to continue to allow this?
My understanding is that they are implicitly forbidden, because coalescing packets belonging to different connections are forbidden, and because there’s nothing to coalesce with when either of the two types of the packets is sent. I am not sure if we need to be more clear on that, considering the fact we generally use MAY for the discarding rules for coalesced packets.
VN certainly causes a new connection based on discussions in Tokyo. Retry does not cause a new connection(ie: same ClientHello). Clarifying this seems wise if it's not already clear.
Yes, however when a Retry packet is being sent, there's nothing a server can send along with. Regarding if we need to clarify, while I do not think it's absolutely necessary, I can see that people might want to have it stated considering the fact that we do utilize corner case rules of coalesced packets (see ).
So, is this editorial?
I'm with NAME but I'm still wondering: what is the clarification that we can provide?

NAME Simply clarifying that "VN and Retry packets will never be coalesced" as part of the changes we would make in might be a good idea. We do not need to use a RFC 2119 word here due to the editorial nature of the issue.
The PR looks good to me, but I think we might want to consider changes like below to better clarify how the design works.