Re: [quicwg/base-drafts] Wrongly hinting of issues not existing for packet number size increase (#605)

[ianswett <[e-mail]>]

@martinthomson The concern you point out is real, though as @mcmanus points out, it just causes a few packets to be dropped when they can't be decrypted in the worst case.

Reordering is somewhat common, but reordering of >100 packets is pretty rare, so even 1 byte works very well in the real world.  

I remember there being some text on how to choose the packet number length, but I can't find it anymore.  The early draft(https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-00) had this text, which I think may have been lost when the packet header was changed?

"To enable unambiguous
      reconstruction of the packet number by the receiver, a QUIC
      endpoint MUST NOT transmit a packet whose packet number is larger
      by (2^(bitlength-2)) than the largest packet number for which an
      acknowledgement is known to have been transmitted by the receiver.
      Therefore, there must never be more than (2^46) packets in flight.
      Any truncated packet number received from a peer shall be inferred
      to have the value closest to the one more than the largest known
      packet number received from that peer.  The transmitted portion of
      the packet number matches the lowest bits of the inferred value."

To be clear, I think this text can be improved, but it's important to have a recommendation both based on number of packets currently outstanding and number that may be sent in the near future(likely limited by CWND).  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/605#issuecomment-309820441