Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to distinguish Client Initial Packet with client Connection ID from one with server Connection ID #577

Closed
igorlord opened this issue Jun 5, 2017 · 2 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@igorlord
Copy link
Contributor

igorlord commented Jun 5, 2017

Current text says that "The client populates the connection ID field with randomly selected values, unless it has received a packet from the server."

We need to be able to tell a different between Client Initial Packet with client-generated connection ID and Client Initial Packet with server-generated connection ID. I would suggest adding a packet type.

@igorlord igorlord changed the title Need to distinguish Client Initial Packet with client and with server Connection ID Need to distinguish Client Initial Packet with client Connection ID from one with server Connection ID Jun 6, 2017
@mnot mnot added -transport design An issue that affects the design of the protocol; resolution requires consensus. labels Jun 27, 2017
@mnot mnot added this to Handshake in QUIC Sep 5, 2017
@martinthomson
Copy link
Member

The current design has Client Initial (or just Initial) packets including a client-chosen connection ID always. Is this still a problem @igorlord?

@igorlord
Copy link
Contributor Author

No. This is no longer an issue. The current design has exactly two packet types that carry client-chosen connection id: "Client Initial" and (client's) "0-RTT" packets.

@martinthomson martinthomson removed this from Handshake in QUIC Oct 20, 2017
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

3 participants