Re: [quicwg/base-drafts] Rewrite text about Version Negotiation (#1039)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> -used - and they MUST be padded to at least 1200 octets.
-
-The server receives this packet and determines whether it potentially creates a
-new connection (see {{packet-handling}}).  If the packet might generate a new
-connection, the server then checks whether it understands the version that the
-client has selected.
-
-If the packet contains a version that is acceptable to the server, the server
-proceeds with the handshake ({{handshake}}).  This commits the server to the
-version that the client selected.
+with an existing connection, or - for servers - potentially create a new
+connection.
+
+First, hosts try to associate the packet with an existing connection. If the
+packet has a connection ID corresponding to an existing connection, QUIC
+processes that packet accordingly. Note that a NEW_CONNECTION_ID frame

I think that this fits nicely with @marten-seemann's comment about handling Initial packets specially.  My pseudocode didn't do this, but this motivates moving the version and Initial packet checks right up front.

> +connection IDs if they do not meet both of these criteria.
+
+
+### Client-Specific Behaviors {#client-specific-behaviors}
+
+If a client receives a packet with an unknown connection ID, and it matches
+the tuple of a connection with no received packets, it is a reply to an
+Initial packet with a server-generated connection ID and will be processed
+accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}. 
+
+Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.

Computation isn't the problem, it's receipt of the server handshake.  Maybe "packets that are protected with 1-RTT keys prior to receiving handshake messages. Packet protection cannot be removed from these packets until the cryptographic handshake produces the necessary keys."

> +accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}. 
+
+Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version

"and length sufficient for the packet to be an Initial packet in any version supported by the server" maybe

> +Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully

Yes, Initial packet.

> +If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the
+handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the
+server MAY buffer a limited number of these packets in anticipation of
+a late-arriving Initial Packet. In the event the server later generates
+a RETRY packet, this buffer should be purged. Servers MUST NOT send packets

The buffer purge is probably a bad idea.  If you consider how you might implement this, the 0-RTT buffer is likely to be global across the entire server.  You can't know when you receive them which connection to associate them with, so it has to be a little bit global.  Choosing to send Retry on one connection shouldn't cause other 0-RTT packets to be purged.  Also, choosing not to accept 0-RTT is another reason you might purge them.

It might be better not to get into details here.  I would probably instead maintain a deque of 0-RTT packets and let new 0-RTT packets push older ones out.  No point ever purging other than when you are scrubbing through looking for unclaimed packets.  Initiating a purge is CPU cycles you don't need to spend.

-- 
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/1039#discussion_r167767760