On Mon, Sep 14, 2020 at 4:20 PM Dmitri Tikhonov <[email protected]> wrote:
> 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. > Care to write a PR to clarify this? > > > > 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. > >
