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

[Nick Banks <[e-mail]>]

nibanks commented on this pull request.



> -A packet that uses the short header could be associated with an existing
-connection with an incomplete cryptographic handshake.  Such a packet could be a
-valid packet that has been reordered with respect to the long-form packets that
-will complete the cryptographic handshake.  This might happen after the final
-set of cryptographic handshake messages from either peer.  These packets are
-expected to be correlated with a connection using the tuple of IP addresses and
-ports.  Packets that might be reordered in this fashion SHOULD be buffered in
-anticipation of the handshake completing.
-
-0-RTT packets might be received prior to a Client Initial packet at a server.
-If the version of these packets is acceptable to the server, it MAY buffer these
-packets in anticipation of receiving a reordered Client Initial packet.
+with an existing connection, or - for servers - potentially create a new
+connection.
+
+Hosts handle packets that can be associated with an existing connection

Personally, I am with Ian here. Delivery of a received packet should be based on the connection ID. Only if the connection ID is omitted, then the 4-tuple would be used.

For (1) & (2) above, I don't care too much if the packets are dropped or delivered to the existing connection. I think delivering to the connection is easier because it doesn't require any knowledge of the connection's state beyond it exists. Depending on the implementation, the UDP receive thread/processing might not have access to the connection's state.

For (3) above, I agree that ideally they would be separate connections, but how do you differentiate the two connection scenario from the retransmission w/ NAT rebinding scenario? Just delivering them to the same connection is simplest.

For (4) above, we should definitely allow a client to create two connections simultaneously with the same 4-tuple. #1041 is also necessary to support this scenario.

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