On Mon, Sep 14, 2020 at 03:40:47PM -0400, Ian Swett wrote: > On Mon, Sep 14, 2020 at 1:54 PM Dmitri Tikhonov wrote: > > The "in full" is not clear. What if the packet number needs more than > four bytes to be encoded? > > The algorithms described in the spec don't allow you to specify a >4 byte > packet number if no prior packets have been sent and received. This isn't > anything new.
The part about "including the full packet number" is just not clear. In particular, does it mean that a 4-byte encoding must be used? One could intepret the spec to mean that a packet number is not to be truncated. So, for example, packet number 123 would fit into one byte. The decoder would use this logic if an ACK was not yet sent, and the other logic if an ACK was sent. Specifying explicitly how many bytes to use to encode a packet number in this case would remove this ambiguity. > > 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! > > To my knowledge, the spec implied this before, but didn't state it > outright. What does your code do when the largest_acked for the PN space > has not yet been received? Our code uses "smallest unacked" (rather than "largest acked") or zero, if nothing has been sent in this PNS yet. This results in 1- or 2-byte encodings. - Dmitri.
