Re: Some questions about Packet Number Encoding And Decoding

["Martin Thomson" <[e-mail]>]

On Tue, Sep 3, 2019, at 13:26, mikewczhou(周雯程) wrote:
>  1. What's the purpose of Packet Number Encoding? to be safe or save 
> 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.