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.

Sign up for GitHub

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

Jump to bottom

Connection migration symmetry #573

Closed
marten-seemann opened this issue Jun 5, 2017 · 3 comments
Closed

Connection migration symmetry #573

marten-seemann opened this issue Jun 5, 2017 · 3 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. future-version An issue that is best addressed in a future version of QUIC, or an extension to it. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
QUIC Transport / Recovery / TLS

Comments

@marten-seemann
Copy link
Contributor

With the introduction of the NEW_CONNECTION_ID logic, a client can perform a connection migration that can't be correlated by an external observer. This works fine in the classic server-client setting, but (as pointed out in the discussion of #491) for p2p connections, both peers might want to perform such a connection migration.
@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Jun 5, 2017
@martinthomson martinthomson added this to Migration in QUIC Jun 5, 2017
@martinthomson
Copy link
Member

See also #490.

@mnot mnot changed the title make connection migration symmetric Connection migration symmetry Jun 20, 2017
@ianswett
Copy link
Contributor

It's believed #560 and Connection Migration(#1012) should be sufficient for the HTTP over QUIC goals of v1, tagging this as v2.

@ianswett ianswett added the future-version An issue that is best addressed in a future version of QUIC, or an extension to it. label Mar 13, 2018
@MikeBishop
Copy link
Contributor

(...with the additional note that if those land and we manage to progess a PR sufficiently, nothing prohibits us from pulling this back.)

@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
@mnot mnot closed this as completed Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. future-version An issue that is best addressed in a future version of QUIC, or an extension to it. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
No open projects
QUIC
Migration
Transport / Recovery / TLS
quicv2
Milestone
No milestone
Development

No branches or pull requests
5 participants
@martinthomson @mnot @marten-seemann @MikeBishop @ianswett