HoLB from NCID frames

[MikeBishop]

Since NEW_CONNECTION_ID frames are defined to be sequential (because the packet number gaps are cumulative), receipt of NCID frames out of order requires reassembly; the later CIDs aren't usable without the previous ones. This is particularly pernicious in the situations described in #1276, where one side is effectively out of CIDs, while the other side believes it has many future IDs issued. In an extreme case, the exhausted side might be unable to send packets at all, causing the other side not to receive ACKs which would permit it to repair the loss.

Possible solutions include:

• Eliminating the packet number gap entirely via Packet number encryption #1079
• Switching from a gap to an offset, so that CIDs need not be used sequentially

In either case, the CIDs associated with a connection would become an unordered set, rather than a list in fixed order.

[mikkelfj]

1079 won't resolve all gaps if optimistic ACK attack protection is on.

[MikeBishop]

The issue here is that the server is currently using CID1 and the packet number has reached A. It has received:

• CID3, gap Y packets
• CID4, gap Z packets

Missing in flight is the frame that says "CID2, gap X packets". It can't use CID3 because it needs to go to packet number A + X + Y, but X is unknown.

So optimistic ACK protection is fine. You don't need there to be no gaps in your own packet number sequence; you need to not be required to introduce a particular gap in your own packet number space that was specified by your peer.

[martinthomson]

Yes, my plan was to resolve #1079 and then later remove the sequence number. Thanks for opening this Mike.

[janaiyengar]

Now that PNE is done, we should remove the sequence number.