RE: Go Back to Single Packet Number Space

[Nick Banks <[e-mail]>]

A lot more has already been discussed related to this on the issue, but I can expand on some of it here.



The design for managing sent packets and handling ACK frames for them for the two designs looks as follows:



Single Packet Space

  *   A single list of sent packet metadata objects, and other loss detection/recovery state (largest packet number, last sent time, RTO timer…).
  *   Each metadata object has 2 bits for tracking encryption level used to send the packet.
  *   On receipt of an ACK frame, encryption level and frame are passed to the ACK processing logic. This logic traverses the list of sent packets and just verifies that the received encryption level >= to the original level.



Multiple Packet Spaces

  *   Three lists of sent packet metadata objects and their associated loss detection/recovery state.
  *   On receipt of an ACK frame, encryption level and frame are passed to the ACK processing logic. The encryption level indicates when sent packet list to search.



The logic complexity of processing the ACK is pretty much the same, but the multiple packet spaces has a lot more state tracking. Additionally, how packet loss works across packet levels is not well explained. With single packet space, there is no extra complexity for cross-packet space loss recovery.



On the side of the acknowledger, there is a lot more complexity. Again, keeping three times the state to track which packets numbers are outstanding in which encryption level is a burden. The most painful part (at least for my code) is when it times to generate all the necessary packets given the current state. Taking those three sets of packet number to acknowledge and generate all the correctly formatted packets in the appropriate encryption levels in quite involved. My logic for deciding what type of packet to frame next and what can/should be put in it still has bugs after working on it for a few weeks. With a single packet number space, you only keep 1 set of packet numbers to acknowledge, and the highest encryption level for a packet number that needs to be acknowledged. Then, you send a single packet, with a single ACK frame at that highest encryption level (or higher), and you are done.



Bottom line, multiple packet numbers require 3 times the state and require a lot of additional logic to manage, both on the send and receive side. IMO, this is a lot of complexity that is not needed, and is overkill for what usually is just 1 or 2 RTT of the entire connection.



- Nick



-----Original Message-----
From: Martin Thomson <[e-mail]>
Sent: Wednesday, July 25, 2018 6:42 PM
To: Nick Banks <[e-mail]>
Cc: QUIC WG <[e-mail]>
Subject: Re: Go Back to Single Packet Number Space



The feedback I've heard is that the simplification is subjective.

Others have said that a single space would complicate their implementation considerably more.  You might want to say more about that.



The loss of acknowledgements during the Initial phase has the unfortunate effect of forcing implementations to rely on implicit acknowledgment.  This doesn't seem like a problem now, but we're close to the quantum computer cryptographic apocalypse (put that on a sandwich board and yell it on street corners folks!) and this sort of reduction in capability could serious impair our ability to ship a key exchange that doesn't have problems.



Now, this latter thing is not an unfixable problem if you cared about it, but it depends on what your real problem is.

On Thu, Jul 26, 2018 at 5:29 AM Nick Banks <nibanks=[e-mail]<mailto:nibanks=[e-mail]>> wrote:

>

> Hello Folks,

>

>

>

> I have opened a GitHub Issue (#1579) and Pull Request (#1591) for this topic, but it seems progressed has stalled, so I figured I should take it to the list.

>

>

>

> While implementing draft-13, I came across a number of pain points related to using multiple packet number spaces. A lot of the issues result in duplicated state (and associated memory) for all the packet number spaces. But more importantly, the multiple packet number spaces bring in a lot more complexity of logic, compared to the previous single packet number space design. There is a lot more detail in the GitHub issue, and I’d ask that folks take a look at it (and the PR) and provide any feedback they might have. I feel that my Issue adequately describes the problem and my PR provides good (if not better, IMO) solutions to the problems that were fixed previously with multiple packet number spaces. I believe having a single packet number space will drastically simplify implementations in the end.

>

>

>

> Finally, as QUIC V1 (2?) is coming to a close (hopefully) I feel like we should resolve this issue soon. I don’t want this issue to slip out into the next version.

>

>

>

> Thanks,

>

> - Nick