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

assign roles after TCP simultaneous connect, describe how hole punching works on QUIC #361

Merged
merged 2 commits into from
Aug 23, 2021

Conversation

marten-seemann
Copy link
Contributor

No description provided.

@marten-seemann marten-seemann changed the title assign roles after TCP simultaneous connect, describe how hole punching work on QUIC assign roles after TCP simultaneous connect, describe how hole punching works on QUIC Aug 22, 2021
Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for preparing a pull request!

On first read, when using TCP, I thought we should instead support both negotiating the role (client / server) in-band via the Multistream Select Simultaneous Open extension and the out-of-band assignment through the DCUtR protocol, as suggested in this pull request.

Thinking about it some more, I am in favor of your suggestion, assigning the role out-of-band through the DCUtR protocol, thus simplifying the process.

Just to make sure I am not missing something, we would thus only need the Multistream Select Simultaneous Open extension for uncoordinated simultaneous TCP connections, correct?

@marten-seemann
Copy link
Contributor Author

Thinking about it some more, I am in favor of your suggestion, assigning the role out-of-band through the DCUtR protocol, thus simplifying the process.

This is essential if we don't want to couple Flare with Protocol Select (as Protocol Select doesn't come with a low-latency option to assign roles in the case of TCP Sim Open).

Just to make sure I am not missing something, we would thus only need the Multistream Select Simultaneous Open extension for uncoordinated simultaneous TCP connections, correct?

That is correct.

@mxinden mxinden merged commit b420064 into rfc/dcutr Aug 23, 2021
@Stebalien
Copy link
Member

Thinking about it some more, I am in favor of your suggestion, assigning the role out-of-band through the DCUtR protocol, thus simplifying the process.

What if I perform a simultaneous open without coordination? As I've pointed out before, this is a very common case and it needs to be supported before we start making changes.

@marten-seemann
Copy link
Contributor Author

@Stebalien There’s a section “Uncoordinated TCP Simultaneous Open” in the Protocol Select spec (#349).

@Stebalien
Copy link
Member

Thanks. I'm mixing issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants