Subject: Some questions about Packet Number Encoding And Decoding

From: mikewczhou(周雯程) <[email-masked]>
Date: Tue, 3 Sep 2019 03:26:42 +0000

Thank you guys a lot! I have some questions about Packet Number Encoding And Decoding
In transport draft Section 17.1. Packet Number Encoding and Decoding
For example, if an endpoint has received an acknowledgment for packet 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe.

  1.  What's the purpose of Packet Number Encoding? to be safe or save some bits space or something else?
A peer receiving the packet will then correctly decode the packet number, unless the packet is delayed in transit such that it arrives after many higher-numbered packets have been received. An endpoint SHOULD use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards.

  1.  How can an endpoint know to use a large enough packet number encoding? For example, as example 1 said, an endpoint can send 16 bits to send a number of 0xac5c02 if peer has received an acknowledgment for packet 0xabe8bc, which means it will send 0x5c02. So in the early time when it want to send 0x5c02 exactly(not 0xac5c02), How should it encode packet number to avoid conflict with 0xac5c02 if the packet is delay so much.
  2.  If an endpoint is not encoded packet number well, the peer will recover it as a wrong packet number, what happens next?

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 03 Sep 2019 15:08:08 +1000

> some bits space or something else?

It's a space-saving measure only.

>  1. How can an endpoint know to use a large enough packet number 
> encoding? For example, as example 1 said, an endpoint can send 16 bits 
> to send a number of 0xac5c02 if peer has received an acknowledgment for 
> packet 0xabe8bc, which means it will send 0x5c02. So in the early time 
> when it want to send 0x5c02 exactly(not 0xac5c02), How should it encode 
> packet number to avoid conflict with 0xac5c02 if the packet is delay so 
> much.

That's in the draft: if you want to include enough bits to allow for reordering of all outstanding packets, then you need log2(this packet - earlier unacknowledged packet)  + 2 bits.  You can obviously get away with less if you expect less reordering, but the fewer bits you use, the greater the risk.  Also note that you can't predict what you might send in future and sending too short a packet number can cause problems if you start sending a lot more packets.

>  2. If an endpoint is not encoded packet number well, the peer will 
> recover it as a wrong packet number, what happens next?

The packet number is used as an encryption/decryption nonce.  So getting the value wrong will mean that the packet won't decrypt and it will be discarded.  That will look like packet loss to you, but the receiver might do things like count the number of bad packets like this and could start to treat your IP address as a potential DoS attacker.

For that, testing is your friend.  If you are concerned about reordering and short numbers, add a few extra bits to the encoding.  But it would need to be a fairly specialized application to need more than 16 bits.  At the minimum packet size, that's a BDP of around 20 megabytes, with reordering of an entire round trip.  That's possible, but not that likely.