RE: Go Back to Single Packet Number Space

[Nick Banks <[e-mail]>]

First, I think we should limit the discussion to what actually is in V1. Things like post quantum crypto and possible future TLS changes are interesting to reason about, but should have no immediate bearing on the design right now. If things change in the future that might cause additional issues, we should handle them in a future version.

Second, on the topic of only acknowledging packets at a greater than or equal encryption level being even harder or less efficient to implement, while I whole-heartedly disagree, I was thinking about this, and feel we could actually go one step further. Already I have proposed disallowing ACKs in Initial packets and allowing 0-RTT packets to be acknowledged in Handshake packets. We could instead just say no ACKs in Initial packets, but all other packets can acknowledge any other packet. No encryption level requirements at all. The obvious possible point of contention with this, is that it would allow Handshake packets to acknowledge 1-RTT packets. While it is a ‘lower’ encryption level (I don’t really know what that means) both Handshake and 1-RTT keys are keys only the endpoints know. I don’t see any harm in temporarily (as long as you accept Handshake packets) allowing Handshake packets to acknowledge 1-RTT packets. With this design, an implementation that needs to acknowledge something can then do whatever it likes, so long as it doesn’t use an Initial packets.

Next, for not explicitly sending ACK frames in Initial packets, I personally don’t see the explicit event of TLS changing read encryption keys from initial to handshake as an implicit signal. To me, it seems very reasonable to call that out as the explicit signal to treat your initial packet(s?) as acknowledged.

- Nick

From: Patrick McManus <[e-mail]>
Sent: Thursday, July 26, 2018 5:15 AM
To: Kazuho Oku <[e-mail]>
Cc: Martin Thomson <[e-mail]>; Nick Banks <[e-mail]>; QUIC WG <[e-mail]>
Subject: Re: Go Back to Single Packet Number Space



On Thu, Jul 26, 2018 at 4:33 AM, Kazuho Oku <[e-mail]<mailto:[e-mail]>> wrote:
I prefer having split packet number spaces, because in addition to
what Martin says, I feel uneasy about allowing a receiver to
acknowledge a packet "in a greater than or equal encryption level."

My understanding is that this the key of the proposal. Use of a
unified packet number space makes sense only when an endpoint can send
an acknowledgement for all packets that it has received in one
encryption level.

This sums up my feelings as well - I really like the explicitness of the separate spaces.