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

Sending NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames when multipath has been negotiated #320

Open
michael-eriksson opened this issue Mar 18, 2024 · 5 comments

Comments

@michael-eriksson
Copy link

It should be explicitly specified if it is allowed/discouraged/forbidden to send NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames (implicitly referencing path ID 0) when multipath has been negotiated.

@mirjak
Copy link
Collaborator

mirjak commented Mar 18, 2024

I think we have to allow it because it could be sent before multipath is "negotiated". Also not that QUIC does really negotiate but rather another, which is another reason why forbidding based RFC frames is generally hard.

We could say this more explicitly but we don't have to because it is a general thing about how QUIC transport parameters work.

@kazuho
Copy link
Member

kazuho commented Mar 19, 2024

FWIW I think we have the option to state that use of multipath, specifically the maximum number of paths, is remembered. Then, endpoints can send the correct frame in 0-RTT too, depending on if the original connection was MP or not.

At the moment, we state that use of multipath is not remembered, but I don't think anybody had a strong argument one way or anotther; see #219.

@huitema
Copy link
Contributor

huitema commented Mar 19, 2024

We can plausibly say that a legacy NEW_CONNECTION_ID frame is equivalent to MP_NEW_CONNECTION_ID with pathID=0. That means it would be allowed at the beginning of the connection, but disallowed if the pathID 0 was Abandoned.

Which brings a related issue. Is it legit to send an MP_NEW_CONNECTION_ID with pathID=N after path N has been abandoned?

@michael-eriksson
Copy link
Author

Indirectly yes, since packets can be reordered and the receiver can't tell the difference. The receiver should obviously ignore the frame like any other stale frame.

@mirjak
Copy link
Collaborator

mirjak commented May 14, 2024

In summary:

  1. NEW_CONNECTION_ID and RETIRE_CONNECTION_ID are still allowed and associated to path ID 0. The document says this already, at least that path ID 0 is used. It doesn't explicit say that these frames can still be used. I don't think that is needed, or would people prefer to be explicit?

  2. Control frames that have an abandoned path ID MUST be ignored. We don't say that explicitly yet. But do we need to add that?

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

No branches or pull requests

4 participants