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.

Sign up for GitHub

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

Jump to bottom

Mention every Transport Parameter in section on values for 0-RTT #3756

Merged
merged 3 commits into from
Jun 23, 2020
Merged

Mention every Transport Parameter in section on values for 0-RTT #3756

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2a269e6
Mention every Transport Parameter in section on values for 0-RTT
nharper Jun 10, 2020
e3d689f
Use active voice and mention why the server might remember these values
nharper Jun 18, 2020
8f45383
Update draft-ietf-quic-transport.md
janaiyengar Jun 23, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
7 changes: 7 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1749,6 +1749,13 @@ values for 0-RTT. This includes initial_max_data and either
initial_max_streams_bidi and initial_max_stream_data_bidi_remote, or
initial_max_streams_uni and initial_max_stream_data_uni.

It is OPTIONAL for a server to be able to recover the previously sent values of
the max_idle_timout, max_udp_payload_size, and disable_active_migration
parameters. Lowering the values of these parameters while also accepting 0-RTT
Copy link
Member

Choose a reason for hiding this comment

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

I know that OPTIONAL and RECOMMENDED are in RFC 2119, but they encourage the passive voice, .

Suggested change
It is OPTIONAL for a server to be able to recover the previously sent values of
the max_idle_timout, max_udp_payload_size, and disable_active_migration
parameters. Lowering the values of these parameters while also accepting 0-RTT
A server MAY choose to recover the previously sent values of the
max_idle_timout, max_udp_payload_size, and disable_active_migration parameters
and reject 0-RTT if it selects smaller values.
Lowering the values of these parameters while also accepting 0-RTT

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that active voice is better than passive voice. However, I think this suggested change changes the meaning slightly: saying the "server MAY choose to recover" refers to the server making a choice at the time it would be recovering, while "OPTIONAL for a server to be able to recover" refers to the server making a choice at the time it is storing (or otherwise encoding) parameters to be able to recover at a future point in time. I'm trying to be more clear that the option (whether active voice MAY or passive voice OPTIONAL) is when storing the transport parameters, not when recovering.

Copy link
Contributor

Choose a reason for hiding this comment

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

Change "MAY choose to recover" to "MAY store and recover". @nharper, any other way of making this active is also good.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"MAY choose to store and recover" sounds good to me.

data could degrade the performance of the connection. Specifically, lowering the
nharper marked this conversation as resolved.
Show resolved Hide resolved
max_udp_payload_size could result in dropped packets leading to worse
performance compared to rejecting 0-RTT data outright.

A server MUST either reject 0-RTT data or abort a handshake if the implied
values for transport parameters cannot be supported.

Expand Down