Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move length-determining fields to the start of STREAM and ACK #277

Merged
merged 1 commit into from Feb 16, 2017
Merged

Move length-determining fields to the start of STREAM and ACK #277

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
31 changes: 16 additions & 15 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -920,28 +920,29 @@ A STREAM frame is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Data Length (16)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (0/16/24/32/40/48/56/64) ...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, we have 8 different offsets. And they 're not even evenly spaced. That's cute.

Jana and I can clean that up in our draft, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a separate issue. I can understand why it is that way. That is, there isn't much value in an 8-bit offset given that you are likely to cram > 8 octets in a single packet, which is the most common case for needing offsets. That said, I think that we would want to discuss what options make sense.

I can see arguments for 0, 16, and 32 and 64 would avoid the need for rollover calculations. The other options seem like overoptimizing. varint encoding would be preferable in that case.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Data Length (16)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #stream-format title="STREAM Frame Format"}

The STREAM frame contains the following fields:

* Data Length: An optional 16-bit unsigned number specifying the length of the
Stream Data field in this STREAM frame. This field is present when the `D`
bit is set to 1.

* Stream ID: A variable-sized unsigned ID unique to this stream.

* Offset: A variable-sized unsigned number specifying the byte offset in the
stream for the data in this STREAM frame. The first byte in the stream has an
offset of 0.

* Data Length: An optional 16-bit unsigned number specifying the length of the
Stream Data field in this STREAM frame.

* Stream Data: The bytes from the designated stream to be delivered.

A STREAM frame MUST have either non-zero data length or the FIN bit set.
Expand Down Expand Up @@ -1007,36 +1008,36 @@ An ACK frame is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acked (8/16/32/48) ...
|[Num Blocks(8)]| NumTS (8) | Largest Acked (8/16/32/48) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Delay (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[Num Blocks(8)]| Ack Block Section (*) ...
| Ack Block Section (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumTS (8) | Timestamp Section (*) ...
| Timestamp Section (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~
{: #ack-format title="ACK Frame Format"}

The fields in the ACK frame are as follows:

* Num Blocks (opt): An optional 8-bit unsigned value specifying the number of
additional ack blocks (besides the required First Ack Block) in this ACK
frame. Only present if the 'N' flag bit is 1.

* Num Timestamps: An unsigned 8-bit number specifying the total number of
<packet number, timestamp> pairs in the Timestamp Section.

* Largest Acked: A variable-sized unsigned value representing the largest packet
number the peer is acking in this packet (typically the largest that the peer
has seen thus far.)

* Ack Delay: Time from when the largest acked packet, as indicated in the Largest Acked
field, was received by this peer to when this ack was sent.

* Num Blocks (opt): An optional 8-bit unsigned value specifying the number of
additional ack blocks (besides the required First Ack Block) in this ACK
frame. Only present if the 'N' flag bit is 1.

* Ack Block Section: Contains one or more blocks of packet numbers which have
been successfully received. See {{ack-block-section}}.

* Num Timestamps: An unsigned 8-bit number specifying the total number of
<packet number, timestamp> pairs in the Timestamp Section.

* Timestamp Section: Contains zero or more timestamps reporting transit delay of
received packets. See {{timestamp-section}}.

Expand Down