-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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. |
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. |
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? |
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. |
In summary:
|
It should be explicitly specified if it is allowed/discouraged/forbidden to send
NEW_CONNECTION_ID
andRETIRE_CONNECTION_ID
frames (implicitly referencing path ID 0) when multipath has been negotiated.The text was updated successfully, but these errors were encountered: