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

[Kazuho Oku <[e-mail]>]

@mikkelfj 
> 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.

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._ ((section 12.2)[https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.12.2}]).

-- 
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#issuecomment-460538290