-
Notifications
You must be signed in to change notification settings - Fork 29
don't store initial_max_path_id for 0-RTT #616
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposing alternate writing.
As this extension only defines new behavior that applies after the handshake is completed, | ||
the initial_max_path_id transport parameter is prohibited to be store for 0-RTT | ||
but needs to be newly advertised for each new connection instead. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we stick to established practice and say:
Endpoints MUST NOT remember the value of the initial_max_path_id
transport parameter they received for use in a subsequent connection. Consequently, none of the new frames frames can be sent in 0-RTT packets, as per Section 7.4.1 of [QUIC-TRANSPORT].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay for me but isn't it the other way around? Because we only define changes for 1-RTT, it is not meaningful to store the transport parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Let's rephrase. I care about the MUST NOT, because it encompasses data like MAX_PATH_ID that are not directly linked to frames. But you are correct about 1RTT frames. So we would have:
Endpoints MUST NOT remember the value of the initial_max_path_id transport parameter they received for use
in a subsequent connection. As specified in {{frames}}, the new frames frames defined in this document MUST
only be sent in 1RTT packets.
Or maybe just:
Endpoints MUST NOT remember the value of the initial_max_path_id transport parameter they received for use
in a subsequent connection.
... which would avoid duplicating a requirement from the "new frames" section.
fixes #607