It seems the minimal packet number length should be 14 bits

[NKTelnet]

According to the current packet number decode algorithm, if the packet number length is set to 7 bits, and the packets arrived disorder more than 64 packet numbers, the decode algorithm will not work properly. For example:

1. the current maximum packet number is 556917, and arrived packet number is 118, packet number length is 7 bits, then the arrived packet number will be decoded to 556918

2. now the current maximum packet number is 556918, and new arrived packet number is 16310 with packet number length 14 bits, then the new arrived packet number will be decoded to 556982. The packet number 556982 is correct and it is 64 bigger than 556918

3. the current maximum packet number is 556982 now, a new arrived packet number is 119 with packet number length 7 bits, then the new arrived packet number will be decoded to 557047. This number is wrong and it should be 556919.

On the internet, 64 packets disorder may happen frequently, so I think the minimal packet number length should be 14 bits

[mikkelfj]

QUIC may be used on some high speed links without reordering concerns. However, it may be worth recommending more than 7 bits for ordinary use.

[kazuho]

We already have a sentence that states when a packet number encoding of certain length can be used. Quoting section 17.1: The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent.

Therefore, I think that the only debate is if we need the 7-bit encoding. My preference goes to retaining it, because it would be useful in some cases, and because I do not think we have new information to reopen the issue.

[martinthomson]

First, there is no 7-bit encoding. It's 8 bits, 16, 24, and 32.

Also, there is no guarantee that following the advice in the spec is sufficient either. You can diligently follow the spec requirements and still have <1RTT worth of reordering cause problems if you suddenly increase the rate of sending packets. If you were sending 8-bit packet numbers, then you suddenly send far more than 128 packets within an RTT, a strict interpretation of the spec might still lead to most of those packets being sent with 8-bit packet numbers. If any of those packets with 8-bit numbers is reordered/delayed by more than 127 packets, then it will be decoded incorrectly when it arrives.

That leads to spurious loss, which is repaired very quickly, but it is less than optimal. To do this perfectly, you have to predict future send rates, which is hard.

But we have discussed this in the past. I don't see any new information either. I'm going to recommend no action on this one.

[NKTelnet]

First, there is no 7-bit encoding. It's 8 bits, 16, 24, and 32.

Also, there is no guarantee that following the advice in the spec is sufficient either. You can diligently follow the spec requirements and still have <1RTT worth of reordering cause problems if you suddenly increase the rate of sending packets. If you were sending 8-bit packet numbers, then you suddenly send far more than 128 packets within an RTT, a strict interpretation of the spec might still lead to most of those packets being sent with 8-bit packet numbers. If any of those packets with 8-bit numbers is reordered/delayed by more than 127 packets, then it will be decoded incorrectly when it arrives.

That leads to spurious loss, which is repaired very quickly, but it is less than optimal. To do this perfectly, you have to predict future send rates, which is hard.

But we have discussed this in the past. I don't see any new information either. I'm going to recommend no action on this one.

Yes, I saw the encoding bits number has been changed to 8, 16, 24, 32. So this issue will only happen when more than 128 packets number is reordered.

I can not understand what “That leads to spurious loss, which is repaired very quickly” means.

Once this issue happens, the related connection may be idle for ever and can not be recovered any more.

[ianswett]

You can recover from the situation, because packets are decoded relative to the largest packet number processed. So the sender has to ensure the gap between the largest acked in that PN space and the PN currently being sent is smaller than

Agreed on no action for this one.

[NKTelnet]

The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent.

"The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent." This does not make sense. In my example, the sender used 8 bits length firstly and when the sender found the 8 bits length is not enough for in flight packets, it began to use 16 bits length. The issue still exists. We can not predict how many packets will be sent by application for now. Once we have used 8 bits length, we can only send 127 packets in flight and wait for response, though the congestion control and stream control allows us to send more than 127 packets and we have more packets to be sent, we can not send one packet more until received ACK. Changing bits length from 8 to 16 at this moment does not resolve this issue.

[marten-seemann]

Once we have used 8 bits length, we can only send 127 packets in flight and wait for response, though the congestion control and stream control allows us to send more than 127 packets and we have more packets to be sent, we can not send one packet more until received ACK. Changing bits length from 8 to 16 at this moment does not resolve this issue.

It does not resolve the issue that some of the 8-bit packets might be reordered and will end up undecryptable. It does solve the issue that at least the 16-bit packets will decode correctly, so the connection will make forward progress.

Agreed on no action for this issue.

[NKTelnet]

Once we have used 8 bits length, we can only send 127 packets in flight and wait for response, though the congestion control and stream control allows us to send more than 127 packets and we have more packets to be sent, we can not send one packet more until received ACK. Changing bits length from 8 to 16 at this moment does not resolve this issue.

It does not resolve the issue that some of the 8-bit packets might be reordered and will end up undecryptable. It does solve the issue that at least the 16-bit packets will decode correctly, so the connection will make forward progress.

Agreed on no action for this issue.

This issue will cause the receiver ""ACK the wrong packet number"" and the related stream will hang for ever.

[marten-seemann]

This issue will cause the receiver ""ACK the wrong packet number"" and the related stream will hang for ever.

That's not correct. If you decode the packet number incorrectly, decryption of the packet will fail, since the packet number is used as the nonce for the AEAD. Really, the worst thing this will happen in this case is that the packet is discarded as undecryptable and eventually detected as lost by the sender.

[NKTelnet]

This issue will cause the receiver ""ACK the wrong packet number"" and the related stream will hang for ever.

That's not correct. If you decode the packet number incorrectly, decryption of the packet will fail, since the packet number is used as the nonce for the AEAD. Really, the worst thing this will happen in this case is that the packet is discarded as undecryptable and eventually detected as lost by the sender.

Thank you very much. I will close this issue.