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

Parsing Ack Delay without ack_delay_exponent #1007

Closed
mcmanus opened this issue Dec 9, 2017 · 2 comments
Closed

Parsing Ack Delay without ack_delay_exponent #1007

mcmanus opened this issue Dec 9, 2017 · 2 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

@mcmanus
Copy link
Contributor

mcmanus commented Dec 9, 2017

Once the TLS handshake is complete, this is indicated to QUIC along with any final handshake octets that TLS needs to send. TLS also provides QUIC with the transport parameters that the peer advertised during the handshake.

Unfortunately Handshake (and Retry) packets can contain ACK frames and be delivered before the transport parameters are provided to QUIC. The ack delay field of the ACK frame cannot be interpreted without the ack_delay_exponent from the transport parameters. This brings back memories of flow control and stream 0.

There are several ways to resolve this, but I'll suggest that non protected packets that contain ACK frames are always encoded with the default ack_delay_exponent.

@ianswett
Copy link
Contributor

Agreed, and I might expand that to include 0RTT packets.

@martinthomson martinthomson added -transport design An issue that affects the design of the protocol; resolution requires consensus. labels Dec 10, 2017
@martinthomson
Copy link
Member

Cleartext, yes, defaults.

The problem with 0-RTT is that it uses transport parameters from the ticket or previous session. We might want to consistently apply transport parameters, rather than mix and match.

martinthomson added a commit that referenced this issue Dec 11, 2017
This makes it clear what the rules are for Initial, Handshake, and Retry
packets for ACK frames.

This doesn't say anything about 0-RTT because I didn't want to put any
extra rules around this.  This should be covered amply by other rules
about transport parameters.

Closes #1007.
@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
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
Development

No branches or pull requests

4 participants