Subject: transport-30 introduces a stealthy new MUST

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 11:35:28 -0400

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.

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?

  - Dmitri.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 11:36:24 -0400

>     2. How can only include the *full* packet number when the header only

s/only/one/

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 14 Sep 2020 16:54:49 +0100

>         GitHub issue where this design change(?) would have been discussed.
The paragraph is an editorialized version of what was in draft 29, section
17.1 and 17.2.3. The work was done on an editorial PR
https://github.com/quicwg/base-drafts/pull/3915.  I don't see any changes
that would have warranted a design issue.

Lucas

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Sep 2020 08:58:32 -0700

>    full packet number MUST be included.

Reading that text, I have no idea what it means. Included in what?

>         allows a maximum of four bytes for this value, which can reach

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

---

From: Ian Swett <[email-masked]>
Date: Mon, 14 Sep 2020 12:14:45 -0400

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.  That's what everyone assumed, but we never said it explicitly from
what I could find.

The intent was to clarify that, but apparently the text isn't clear enough.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 13:44:58 -0400

Hi Lucas,

I reviewed the sections of transport-29 you highlighted as well as
PR 3915.  The requirement went from "0-RTT packets *could* need to
use a longer PN encoding" to "the full packet number MUST be included
before receiving an ACK for a PN space."

There are two reasons why I believe this to be a design change:

    1. This is a new MUST.

    2. This requirement will trigger a code change in lsquic.  Were
       it an editorial change only, this would not be the case.

  - Dmitri.

On Mon, Sep 14, 2020 at 04:54:49PM +0100, Lucas Pardue wrote:
>    On Mon, Sep 14, 2020 at 4:35 PM Dmitri Tikhonov
>    <[1][email-masked]> wrote:
> 
>      Hello,
> 
>    [2]https://github.com/quicwg/base-drafts/pull/3915.  I don't see any
>    changes that would have warranted a design issue.
>    Lucas
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]
>    2. https://github.com/quicwg/base-drafts/pull/3915

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 13:54:07 -0400

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

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-masked]> wrote:
> 
>      > This requirement was added in
>      35b28e13aa41ebc53b3e053a8b52868bfb81a8e8,
>    1. mailto:[email-masked]

---

From: Ian Swett <[email-masked]>
Date: Mon, 14 Sep 2020 15:40:47 -0400

> The "in full" is not clear.  What if the packet number needs more than four

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.

> 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?

I'm

> >      >    Prior to receiving an acknowledgement for a packet number
> space,
> >      the
> >      >     2. How can only include the *full* packet number when the
> header
> >      only

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 16:19:32 -0400

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 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 not what I assumed.  Of course, one may argue that the current
>      lsquic approach is buggy -- but I was simply going by the spec!
> 

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.

---

From: Ian Swett <[email-masked]>
Date: Mon, 14 Sep 2020 16:24:32 -0400

> this case would remove this ambiguity.

Care to write a PR to clarify this?

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 16:36:26 -0400

On Mon, Sep 14, 2020 at 04:24:32PM -0400, Ian Swett wrote:
> On Mon, Sep 14, 2020 at 4:20 PM Dmitri Tikhonov wrote:
> 

Assuming that mandating the 4-byte encoding is what's intended.  Or is it
rather a "do not truncate" rule (which is also Christian's reading)?

I also remember there being a part in one of the drafts limiting the range
of (small "i") initial packet numbers, but I cannot find this text now.
Has it been subsumed (possibly by this rule)?

  - Dmitri.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Sep 2020 09:43:43 +1000

> rather a "do not truncate" rule (which is also Christian's reading)?

It's "don't truncate".  That is, don't send a packet number using an encoding that would drop a bit that is set.  If you do, the other side (probably [1]) won't be able to read it.

You can achieve that by sending longer encodings, but you probably [1] don't have to.  Needing 4 bytes requires conditions I can't really conceive of.

[1] It is in theory possible to have the other side receive a significant number of packets and for those packets to be unacknowledged.  But that would require at least 256 packets (plus gaps) to be sent and not acknowledged.  Thus, this is probably mostly academic, even for those implementations that don't set the packet number to zero for each new packet number space.  I've never seen an interop runner test, even at its ridiculous loss rates, reach nearly that many packets.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 23:01:12 -0400

On Tue, Sep 15, 2020 at 09:43:43AM +1000, Martin Thomson wrote:
> It's "don't truncate".  That is, don't send a packet number using an
> encoding that would drop a bit that is set.  If you do, the other side
> (probably [1]) won't be able to read it.

I misread the spec, then -- thankfully (no code change).

Thank you,

  - Dmitri.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 14 Sep 2020 23:13:39 -0400

> Care to write a PR to clarify this?

Now that I know what is meant, I struggle to find an improvement to
the sentence in question.  Nevertheless, I gave it a shot:

  https://github.com/quicwg/base-drafts/pull/4098

  - Dmitri.