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

Connection Migration section should talk about client and server, not endpoint and peer #4125

Closed
marten-seemann opened this issue Sep 22, 2020 · 5 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@marten-seemann
Copy link
Contributor

We decided to only specify client-initiated connection migration in QUIC v1. The section about Connection Migration mostly talks about endpoint and peer though, which makes it really hard to parse. I haven't implement migration yet in quic-go, and reading this section confused me at multiple places.

I believe that specifying the role of the endpoint would make things a lot clearer, and could offer to come up with a PR.

@larseggert larseggert added this to Triage in Late Stage Processing via automation Sep 22, 2020
@ianswett ianswett added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Sep 22, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Sep 22, 2020
@martinthomson
Copy link
Member

I don't think this is worth doing, but would look at a PR.

@ianswett
Copy link
Contributor

To clarify, this would only apply to connection migration, not the path validation section that immediately precedes it.

@janaiyengar
Copy link
Contributor

@marten-seemann: The idea was to keep the migration mechanisms generic, since they can be applied to either endpoint. However, this isn't adequate if we support migration at both ends, since you'd have to deal with other situations, such as simultaneous migration. v1 simply limits the scope of where these mechanisms ought to be applied.

There's value in that, but I understand your reservations. Like @martinthomson, I'm not keen to follow the premise of this issue, but I'd be open to a PR. I'd also be open to clarifying the parts you found confusing.

@ianswett
Copy link
Contributor

Looking at that section again, I don't believe I want to do anything about this issue.

@martinthomson
Copy link
Member

This choice was deliberate. Maybe it's nicer, but now is not really a good time.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Sep 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Development

No branches or pull requests

5 participants