Hello Ian, On Mon, Sep 14, 2020 at 12:14:45PM -0400, Ian Swett wrote: > If no prior packets have been received, then the PN must be stated in > full, since there's no prior packet number to use to decode a truncated > packet number.
The "in full" is not clear. What if the packet number needs more than four bytes to be encoded? > That's what everyone assumed, but we never said it > explicitly from what I could find. That's not what I assumed. Of course, one may argue that the current lsquic approach is buggy -- but I was simply going by the spec! > The intent was to clarify that, but apparently the text isn't clear > enough. Stating that the packet number must use the longest possible encoding (rather than "encoded in full") would be must clearer. - Dmitri. > On Mon, Sep 14, 2020 at 11:59 AM Christian Huitema > <[1][email protected]> wrote: > > On 9/14/2020 8:35 AM, Dmitri Tikhonov wrote: > > > Hello, > > > > There is a new paragraph in transport-30: > > > > Prior to receiving an acknowledgement for a packet number space, > the > > full packet number MUST be included. > > Reading that text, I have no idea what it means. Included in what? > > > > > This requirement was added in > 35b28e13aa41ebc53b3e053a8b52868bfb81a8e8, > > while the actual "MUST" was added in > f009224fcd784f2e5ea88bdb11dcdb4adfb0badd > > > > I have two problems with this change: > > > > 1. The new requirement does not seem to have had a corresponding > > GitHub issue where this design change(?) would have been > discussed. > > > > 2. How can only include the *full* packet number when the header > only > > allows a maximum of four bytes for this value, which can reach > > 2^62 - 1? > > Reading again and speculating, I think the intent is to say that when > starting to use a number space, packet numbers shall be encoded in full > in the packet header. The truncation mechanisms shall only be used after > an acknowledgement from the peer has been received. This means a node > cannot send packet numbers larger than 2^32-1 before receiving an > acknowledgement. If that's the intent, then it is fine. But the current > text is a bit hard to parse. > > -- Christian Huitema > > References > > Visible links > 1. mailto:[email protected]
