Subject: Re: [quicwg/base-drafts] Transport integer encoding proposal (f2f8113)

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Oct 2017 04:06:51 -0700

See also https://github.com/martinthomson/quic-int

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24955127

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 12:23:38 +0000 (UTC)

I think this is a good format, and I am especially happy with the stream id range. Some additional perspective:

Should it be required that an integer is encoded in canonical form, i.e. the smallest possible representation. If so, it would be possible to lexicographically compare two integers when encoded in big endian format.

Additionally, if a sign were to be added for any reason, this could be done by halfing the range of each size and use the MSB 0 to indicate negative and MSB 1 to represent positive. This is neither ones nor twos complement, but it makes it much easier to store in binary search trees or in tries, and again, it allows for direct lexicographical comparison.

Another thought: The UTF-8 encoding format could also be a starting point for an encoding, but I prefer the current proposal.

I have not looked closely at the benchmark implementation, but from other highperformance tests on integer encodings I have learned that the fastest way to decode values is to hardcode a binary search path in code, here with two branches that can efficiently utilize branch prediction.

if data[0] < 0x02 then { if data[0] < 0x01 then mask and read 1 byte else mask and read 2 bytes } else { if data[0] > 0x02 then mask and read 8 bytes else mask and read 4 bytes }

This is much better than table lookup. Each branch can then directly read the number of bytes required while also doing endian conversion.

As this small piece of code can be in a single function it is likely to be in hot instruction cache, and it can also inline efficiently if call overhead is dominating.

The previous format required storing the sizes in different temporary variables after reading the frame type flags which is likely more wasteful in terms of registers, code size and cache.

For some specific integer fields it might make sense to restrict the range, for example (not saying it should be so), a padding frame might start with a length which is at most one byte in length, but allowing for repeat padding frames.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24956525

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 06:10:38 -0700

"Contain" might not be the right word. The FIN bit indicates the frame that ends with final offset of the stream. There is exactly one such frame for normally terminated streams and there is at most one such frame for streams that are reset.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957409

---

From: Brian Trammell <[email-masked]>
Date: Fri, 13 Oct 2017 06:12:07 -0700

+1 to this proposal (IIRC it's pretty much what was discussed at the Paris interim).

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957446

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 06:12:20 -0700

that is, the frame contains the first octets of a stream, or no octets if the FIN bit is also set.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957448

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 06:15:57 -0700

Is there any requirement that stream frames are sent in order? I believe there should be such a requirement, although packets can still arrive out of order.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957546

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 06:18:12 -0700

When is this not the case? Error codes?

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957616

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 13:19:42 +0000 (UTC)

See also my review comment on integer encoding format. I should probably have written those comments here instead.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957655

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 06:22:04 -0700

in a small number of octets. Minimal is a heavy claim.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957698

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 13:39:55 +0000 (UTC)

why is the final gap repeated?

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957970

---

From: Nick Banks <[email-masked]>
Date: Fri, 13 Oct 2017 13:41:14 +0000 (UTC)

I personally like this proposal, though I do have one comment related to the ACK frame changes. WinQuic tends to parse and build these frames from smallest to largest packet number. It used to just require a minor equation to calculate the end based on the number of blocks/gaps. That would no longer be possible with this design.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24957992

---

From: Nick Banks <[email-masked]>
Date: Fri, 13 Oct 2017 13:42:03 +0000 (UTC)

It's not repeated. It's `0` to indicate no more gaps follow.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958005

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 13:47:08 +0000 (UTC)

This is confusing. How can there be any packets in addition to the largest? It is not clear if the ack blocks and gaps are in ascending or descending order. I know it was also confusing before, but I think it needs to be reformulated. I really don't understand no matter how often I read it, and have resorted to inspecting source code.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958104

---

From: ianswett <[email-masked]>
Date: Fri, 13 Oct 2017 06:48:52 -0700

You call it scale above and exponent here.  I think this is better named a shift, correct?

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958136

---

From: ianswett <[email-masked]>
Date: Fri, 13 Oct 2017 06:55:43 -0700

I'm fine with removing the 255 limit, but I'd prefer to actually indicate how many blocks follow rather than having a special terminal value, because then we can say every block and gap is 1 larger than the encoded number.  This prevents blocks of length 0, which are no longer useful.  I heard a few people at the interim complain that blocks of length 0 should be disallowed.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958277

---

From: ianswett <[email-masked]>
Date: Fri, 13 Oct 2017 13:57:35 +0000 (UTC)

+1, I think this should always be true now?

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958321

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 07:05:31 -0700

On the ACK block encoding, I find it hard to read, and have always had problems with interpreting the text since I first encountered QUIC.

I propose removing the largest acked since it isn't really guaranteed to be the largest the peer has seen.

Instead have the following structure:

```
First Ack Packet (in this frame) (varlen) (present exactly once)
First Ack Block Length (varlen, non-zero)
{Gap length (varlen, non-zero), Ack Block length (varlen, non-zero)} repeated 0 or more times.
Terminal Gap (varlen, always-zero)
```

"There is a least one packet acknownledged by the ACK frame and it is identified by the First Ack Packet. The First Ack Block Length indicates the number of consequtive packets being acknowledged, starting with the First Ack Packet. Additional ranges can be ackowledged by skipping Gap length packet numbers to reach the start of the next Ack Block and the length of this block is given the Ack Block length field. Pairs of (Gap Length, Ack Block Length) can be repeated zero or more times until the Gap length is encoded as a zero."

Note: there is special case of only acknowleding one packet where the First Ack Block Length could be encoded in a more compact format. If this is relevant, The First Ack Block could be the only value present and have a dedicacated flag to encode this.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958496

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 07:09:37 -0700

See also my proposal in the comments section below. I could also see a block count instead of a terminal Gap - I disallowed zero length blocks. Though, terminal value or block count, I don't think it makes much difference.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958587

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 14:10:30 +0000 (UTC)

The text states that it is repeated.  ```+Final Gap (repeated):```

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958602

---

From: ianswett <[email-masked]>
Date: Fri, 13 Oct 2017 14:12:51 +0000 (UTC)

Agreed, it needs to be clarified they're in descending order prior to discussing the math, because it's confusing.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24958664

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 09:34:24 -0700

Nit: this phrasing is a bit clumsy. Given that you have a field below, I would say instead:
"These two bits encode the log base 2 of the length of the field" 

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961766

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:35:30 +0000 (UTC)

I would say instead that it is an unsigned number in the range 0..2^62-1.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961781

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:38:23 +0000 (UTC)

Since we're bikeshedding the grammar here, I suggest a semicolon

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961811

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:39:52 +0000 (UTC)

I'm not sure this is worth it. I would just do microseconds with a straight integer encoding.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961831

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:41:00 +0000 (UTC)

Ian's suggestion would also have the virtue that you can read the fixed part of the frame and know how long it is.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961842

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:43:25 +0000 (UTC)

This is a nit, but I don't think that I would phrase this as being 8 types but rather as "the stream frame has the top bits XXX and then the low bits mean ..."

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961871

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 09:43:45 -0700

Typo: TH

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961878

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:43:54 +0000 (UTC)

A variable

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961884

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:44:34 +0000 (UTC)

You should use a consistent phrasing for this and the previous bit. In that one you describe the 0 case as well.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961904

---

From: ekr <[email-masked]>
Date: Fri, 13 Oct 2017 16:45:37 +0000 (UTC)

Github went berserk with the comments, but I would say I think this is pretty good. I added some comments.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24961920

---

From: MikkelFJ <[email-masked]>
Date: Fri, 13 Oct 2017 17:07:50 +0000 (UTC)

Another point is having a limit on the number blocks. If this limit is 255 it is viable to stack allocate structures to represent the decoded frame. This is possible in the previous ACK format, and also necessary due to the complex encoding. With my ACK proposal of incrementing ACK blocks, there is less need to preprocess the ack blocks because you can just process a block at a time, assuming the unacked blocks are stored in a sorted list ordered by packet number. Therefore the need for limiting the number of ACK blocks might go away. This in turn can also lead to having at most one ACK frame per packet which could simplify processing - not sure how important that is since a packet must be fully validated before being acted upon, but still...

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24962343

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Oct 2017 23:01:45 +0000 (UTC)

@ianswett pointed out that a typical ACK delay exceeds the maximum value that can be expressed in two octets and was concerned about adding two octets to every ACK frame.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24994764

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Oct 2017 23:03:49 +0000 (UTC)

Rather than number the blocks, which still doesn't tell you how long the frame is, I would rather add a length field to the frame.  We can then debate whether we then want that length to be added to every frame type and how.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24994783

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Oct 2017 16:10:12 -0700

Separate issue.  Though given that it can't be policed, I'm not sure what value the requirement would have in practice; we could certainly recommend it.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24994807

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Oct 2017 23:21:04 +0000 (UTC)

There is a more dramatic change to the design that would allow in-order construction, avoid negative-valued overflows, and would save an occasional octet:

ACK = Length *(Gap ACK_Block) Delay

Assuming that gaps and blocks are all positive values rather than negatives.  It makes acquiring the largest acknowledged more difficult (it would be the sum of the sequence of gaps and blocks), but it would avoid some of the stranger parts of the current design (and address @nibanks concern about ordering).

I wanted to do that separately though.  I'm trying to make only one change at a time.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-24994840

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 20:57:58 +0000 (UTC)

+1, this is a shift, not an exponent.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25015983

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 14:14:46 -0700

This is a long run-on sentence. In general I prefer succinct statements to spelled out arithmetic operations, since they're clearer. So, I'll offer a suggestion and then a suggested rephrasing. I think it'll be useful to have notation for encoding and decoding operations (say, e() and d()). If we had such, here's a potential rephrasing:

The ACK Delay field encodes a value that MUST be scaled to get the actual acknowledgement delay. The  ack_delay_exponent transport parameter set by the sender of the ACK frame indicates the number of left shifts, as described in Section XX. The actual acknowledgement delay value in microseconds is then computed as follows (using the "C" notation "<<" for left-shift):
 
acknowledgement delay = d(ACK Delay) << ack_delay_exponent

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25016347

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 14:21:59 -0700

TCP recommended delayed ack is 200ms (even though QUIC uses a smaller value), and 16 bits is 64ms. I like the way this is done in this PR, with a default shift of 3 -- which gives you ~500ms -- but an endpoint can indicate differently. 500ms is a few RTTs, which is also large enough to handle reordering when the largest acked is received out of order, causing the ack delay to increase as subsequent lower packet numbers are acked.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25016508

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 14:23:59 -0700

I would definitely prefer a # blocks to a byte-length field. It's not so much about how much to read from the wire, but about how many ranges to allocate when parsing and recording the ack locally. Separately, I think we should indicate somewhere, if we don't already, that an ACK frame MUST fit within a packet.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25016538

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 21:30:28 +0000 (UTC)

I think this proposal is basically good. 

That said, I'll ask again that it's a lot easier to discuss issues if they aren't all conflated in one PR. I understand that they seem related, but then the entire protocol is related. This PR purports to change the integer encoding, but it's revamping the ACK frame structurally and changing the ack delay time format in addition. I would ask that you please separate them into separate PRs.

If you want to change the design of the ACK frame format, please make that a separate issue, and let's agree on what's useful there.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25016684

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Oct 2017 03:11:09 +0000 (UTC)

https://wikimedia.org/api/rest_v1/media/math/render/svg/ae814346939ac31086e1d0286c41d98e6b053102

It's an exponent.  Now, we can improve the description (and even implement it with a binary left shift), but a shift implies other things.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25021392

---

From: martinduke <[email-masked]>
Date: Tue, 17 Oct 2017 03:34:38 +0000 (UTC)

Regarding the time delay format, would it be too simple to just have a bit in the ACK flags that specifies milliseconds or microseconds for that frame? Does 1 us - 64 sec (or 16 sec assuming Martin's other change) give us enough dynamic range for the vast majority of applications in a 2B encoding?

This would also allow the scaling to be per-ack-frame rather than something negotiated, which isn't a big deal, but meh.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25021681

---

From: martinduke <[email-masked]>
Date: Mon, 16 Oct 2017 20:50:26 -0700

Regarding the 2 bits to encode the length, I see significant pros and cons for the simplicity of implementation. It's good to get rid of the thicket of different encodings to figure out how big the fields are. That's probably worth losing the 0-byte offset option, etc.

I also agree that this handles ACK corner cases better. 

On the other hand, this makes it hard to figure out how big anything is supposed to be before parsing the entire thing. This is somewhat annoying when you're doing this in kernel space and dealing with skbuff-like structures, and means I have to check for the end of the datagram (a malformed frame) on essentially every field in an ACK, rather than once per frame.

I would also like to understand how this affects long form headers. The fixed size of fields in long form headers is an important innovation that makes things much easier to handle between versions, etc.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25021848

---

From: martinduke <[email-masked]>
Date: Tue, 17 Oct 2017 03:53:12 +0000 (UTC)

> I propose removing the largest acked since it isn't really guaranteed to be the largest the peer has seen.

There are strong incentives for it to be so. If I always send an accurate largest_acked, then my PCB only need to store the receive time of the highest packet number. If l choose largest_acked to be any other packet, I have to essentially store the receive time of that packet as well.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25021872

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 21:02:55 -0700

@martinduke, this only affects frame encodings.  The packet headers don't change at all.

I have retained the 0-byte offset (and the remainder-of-the-packet length flag) so that this is a minimal change.  We could consider its value separately.

Are you arguing for length-prefix rather than count-prefix?  I think that we'll probably want to poll implementers about that point.  The cost of this sort of encoding is that you have to read the frame to learn how long it is.  The trade-off is, I think, between different decoder costs (length allows you to skip the frame and parse at leisure, count allows you to know how many ranges to allocate), vs. encoder costs (length seems to be strictly harder because it requires that you encode or calculate first and then backfill the length, this in part is why the variable integer encoding permits longer encodings to include small values).

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25021966

---

From: martinduke <[email-masked]>
Date: Mon, 16 Oct 2017 21:31:32 -0700

@martinthomson I might have been confused by the changes at the very top regarding packet numbers. Perhaps this only applies to packet numbers in ack frames? Perhaps some clarifying language is in order.

I apologize for not reading the PR more carefully to see the limited scope of this change. To be honest, if this only applies to select fields in certain frames, while other fields (encoding the same thing!) use the old style encoding, I'm less in love with the idea. If we're going to do this, I'd just as soon make this standard for all integers except for the ones that aren't really numbers (just Conn ID and Version, I think). We can make a special rule that Packet Number in Long Headers MUST have the 10 encoding. Then we free up tons of bits in flags fields all the way through QUIC.

Alternatively, make the ACK frame a special snowflake with different encodings and put all the notation language there. ACK already has odd encodings, and this seems to be the only straightforward way to solve certain problems in the ACK..

> Are you arguing for length-prefix rather than count-prefix?

I am not sure what I am arguing for. This problem seems limited to the ACK frame, so perhaps the answer is to do both. I agree that there are significant drawbacks to either approach. I'll mull it over a bit more.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25022218

---

From: janaiyengar <[email-masked]>
Date: Tue, 17 Oct 2017 04:39:13 +0000 (UTC)

@martinthomson I know what an exponent is. We have used shift in similar cases for TCP window scale (see https://tools.ietf.org/html/rfc7323#section-2.2), so a shift in this context is pretty clear, IMO.

-- 
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/commit/f2f8113a72f94523a53f1180b1a1c0bfa4d6eef4#commitcomment-25022332