Subject: [quicwg/base-drafts] It is not clear how long the fields are (#4291)

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Oct 2020 07:13:06 -0700

>17.2.  Long Header Packets

How is the following encoded? It is not clear how long the fields are.
If the notation is that (x) means x bits it would be good to remind the
reader. It may have been called up earlier but that was 100 pages ago with no
back pointer. This would be so much clearer to most readers with a conventional
packet diagram

>  Long Header Packet {
    Header Form (1) = 1,
    Fixed Bit (1) = 1,
    Long Packet Type (2),
    Type-Specific Bits (4),
    Version (32),
    Destination Connection ID Length (8),
    Destination Connection ID (0..160),
    Source Connection ID Length (8),
    Source Connection ID (0..160),
  }

-- 
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/4291

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Oct 2020 12:57:52 -0700

First, the diagrams are merely illustrative.  If the text is not clear how long the fields are, that's an issue we should fix.  However, the text seems to be fairly concrete about that for most of these fields:

> Header Form:
> The **most significant bit (0x80) of byte 0 (the first byte)** is set to 1 for long headers.
>
> Fixed Bit:
> **The next bit (0x40) of byte 0** is set to 1. Packets containing a zero value for this bit are not valid packets in this version and MUST be discarded.
>
> Long Packet Type:
> **The next two bits (those with a mask of 0x30) of byte 0** contain a packet type. Packet types are listed in Table 5.
>
> Type-Specific Bits:
> **The lower four bits (those with a mask of 0x0f) of byte 0** are type-specific.
> 
> Version:
> The QUIC Version is a **32-bit** field that follows the first byte. This field indicates the version of QUIC that is in use and determines how the rest of the protocol fields are interpreted.
>
> Destination Connection ID Length:
> **The byte** following the version contains the length in bytes of the Destination Connection ID field that follows it. This length is encoded as an **8-bit** unsigned integer. In QUIC version 1, this value MUST NOT exceed 20. Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet. In order to properly form a Version Negotiation packet, servers SHOULD be able to read longer connection IDs from other QUIC versions.
> 
> Destination Connection ID:
> The Destination Connection ID field follows the Destination Connection ID Length field, which indicates the length of this field. Section 7.2 describes the use of this field in more detail.
>
> Source Connection ID Length:
> **The byte** following the Destination Connection ID contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as a 8-bit unsigned integer. In QUIC version 1, this value MUST NOT exceed 20 bytes. Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet. In order to properly form a Version Negotiation packet, servers SHOULD be able to read longer connection IDs from other QUIC versions.
>
> Source Connection ID:
> The Source Connection ID field follows the Source Connection ID Length field, which indicates the length of this field. Section 7.2 describes the use of this field in more detail.

We should probably clarify that DCID/SCID lengths *in bytes* are given by the Length fields; that's not explicitly stated in the text.

As to the diagram format, I repeat my comment from the other issue:  A backref from every diagram seems excessive to me; the document has a Notational Conventions section for terms and notations which are used throughout the document, and this is one of those.

-- 
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/4291#issuecomment-718173916

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Oct 2020 23:42:30 -0700

@MikeBishop, I think that it is clear:

> The byte following the version contains the length **in bytes** of the Destination Connection ID field that follows it.

Based on that, I don't see any action here.

-- 
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/4291#issuecomment-718396374

---

From: Mike Bishop <[email-masked]>
Date: Thu, 29 Oct 2020 06:16:02 -0700

@martinthomson, amazing how easy it is to read straight past what you're looking for.  Yep, agreed.

-- 
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/4291#issuecomment-718744911