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

Separate transport parameters for 0-RTT #126

Closed
martinthomson opened this issue Jan 6, 2017 · 3 comments
Closed

Separate transport parameters for 0-RTT #126

martinthomson opened this issue Jan 6, 2017 · 3 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@martinthomson
Copy link
Member

TLS provides an extension that limits the amount of data that can be sent during 0-RTT. This is an explicit configuration item, even though TCP flow control would naturally limit the amount of data a client can send to a server with 0-RTT. The reason for this is that servers might have to hold some or all of the 0-RTT data. That buffering might be part of replay mitigation, for example. A server that supports 0-RTT can use that limit to ensure that it doesn't have to buffer more than it is willing to buffer.

In #122, I have chosen to carry over the values for initial flow control window and concurrent stream limit. We might want to provide separate transport parameters for 0-RTT so that servers can apply lower limits.
@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Jan 6, 2017
@janaiyengar
Copy link
Contributor

We could provide default minimums that are used by clients that have no server values yet.

@janaiyengar janaiyengar added the needs-discussion An issue that needs more discussion before we can resolve it. label Jan 14, 2017
@mnot mnot changed the title Provide separate transport parameters for 0-RTT Separate transport parameters for 0-RTT Jan 20, 2017
@mnot
Copy link
Member

mnot commented Jan 24, 2017

Discussed in Tokyo; agreement in the room that parameters define defaults, and clients SHOULD cache parameters and MUST use default values if the client doesn't cache. The server always has the ability to kick unruly clients.

@mnot mnot added editor-ready and removed needs-discussion An issue that needs more discussion before we can resolve it. labels Jan 24, 2017
martinthomson added a commit that referenced this issue Feb 7, 2017
@martinthomson
Transport parameters during 0-RTT are either remembered or defaults
c3d7e70 
This changes the definition for transport parameters from "MUST remember"
as I originally wrote up, to the frankly insane consensus position from
the Tokyo interim.

Closes #126
@martinthomson martinthomson mentioned this issue Feb 7, 2017
Merged
martinthomson added a commit that referenced this issue Feb 20, 2017
@martinthomson
Transport parameters during 0-RTT are either remembered or defaults
8847936 
This changes the definition for transport parameters from "MUST remember"
as I originally wrote up, to the frankly insane consensus position from
the Tokyo interim.

Closes #126
@mnot mnot removed the editor-ready label Mar 7, 2017
@mnot mnot reopened this Apr 19, 2017
@martinthomson
Copy link
Member Author

Not sure why this was reopened. It is fixed.

@MikeBishop MikeBishop mentioned this issue Jul 10, 2018
Closed
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@martinthomson @mnot @janaiyengar