Subject: [quicwg/base-drafts] Consider making long header payload length 16bits (#1577)

From: David Schinazi <[email-masked]>
Date: Tue, 17 Jul 2018 08:39:43 -0700

Currently using variable-length encoding for the long header payload length complicates implementations because the payload length is not necessarily known at the start of payload assembly. One solution is to have a separate buffer and/or copy the payload when complete. What several implementations end up doing is to always use the two-byte variant of variable length encoding  for all values 0-16383. Making this a 16bit field would allow all values 0-65535 and simplify implementations.

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 17 Jul 2018 09:13:19 -0700

I agree

-- 
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/1577#issuecomment-405639408

---

From: Marten Seemann <[email-masked]>
Date: Tue, 17 Jul 2018 09:18:12 -0700

You need to know the length you're about to write in order to not overflow the maximum packet size. I had no problem whatsoever using the smallest possible varint representation for the payload length.

-- 
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/1577#issuecomment-405640964

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2018 11:18:57 -0700

Can't you just use the 16-bit encoding always?  You can encode small values on 2, 4, or 8 octets if necessary.

-- 
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/1577#issuecomment-405678442

---

From: David Schinazi <[email-masked]>
Date: Tue, 17 Jul 2018 11:20:32 -0700

You absolutely *can* do that, but it might make implementor's lives easier to use a fixed-width encoding 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/1577#issuecomment-405679199

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Jul 2018 11:56:27 -0700

We discussed something similar in #1301 

-- 
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/1577#issuecomment-405690472

---

From: janaiyengar <[email-masked]>
Date: Wed, 18 Jul 2018 06:52:25 -0700

+1. I'm noticing also that everyone is using a 2-byte PN, I think it makes sense to just use that. Varlen is overkill.

-- 
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/1577#issuecomment-405938589

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 18 Jul 2018 12:51:40 -0700

I oppose.

We currently have a consistency is using varint type for expressing offsets, lengths. Using int16 just for this length type destroys that consistency, thereby makes the design unnecessary complex.

>From the encoder side, most people not interested in saving one octet can always use a two-octet encoding.
For the decoder side, people can use their varint decoder, that they have been consistently using for decoding lengths.

-- 
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/1577#issuecomment-406053246

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 18 Jul 2018 13:10:43 -0700

I agree with @kazuho, for the same reasons.

-- 
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/1577#issuecomment-406058693

---

From: Nick Banks <[email-masked]>
Date: Wed, 18 Jul 2018 14:20:38 -0700

I disagree that changing the length to a 2-byte field increases complexity. Maybe things aren't quite as consistent, but the code to read the field isn't going to drastically increase in complexity because of it. It would likely get a tad bit simpler too. Additionally, I don't think we need to worry about allowing for the _possibility_ that someone really wants to save a single byte in a long header (only during the handshake).

-- 
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/1577#issuecomment-406078137

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 18 Jul 2018 14:26:59 -0700

@nibanks, I think that this sort of issue is "six one way, half dozen the other."  I think we should avoid making changes of this sort lest there be a good reason.  As it stands, it is trivial to both write and read the current varint encoding.

With regard to expressible range:  For packet sizes larger than 16K, it is permissible to splurge and encode their length using 4 bytes.

-- 
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/1577#issuecomment-406079787

---

From: Nick Banks <[email-masked]>
Date: Wed, 18 Jul 2018 21:35:11 +0000 (UTC)

Actually, @dtikhonov I think the expressible range maybe the biggest non-bikeshed reason to use a 2-byte field. Everyone is always using 2 bytes because they build up the contents first (because they don't know the final length upfront) and then go back and fill in those two bytes they preallocated essentially. But if a complete solution wants to support maximum 64K UDP payload sizes, that logic gets a lot more complicated. Either they always preallocate 4 bytes or they have to precalculate the size, which is hard enough that nearly all implementations don't do that already.

-- 
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/1577#issuecomment-406081808

---

From: Marten Seemann <[email-masked]>
Date: Wed, 18 Jul 2018 15:31:06 -0700

I agree with @kazuho and @dtikhonov here. There's value in consistency, and we changed the encoding of values just for the sake of consistency before (last time for the ODCIL field in the retry 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/issues/1577#issuecomment-406094580

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 18 Jul 2018 18:55:05 -0700

@nibanks, you are making a good point.  I withdraw my objection.

-- 
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/1577#issuecomment-406129396

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 18 Jul 2018 19:08:18 -0700

@nibanks That argument stands for many other fields. Initial.token_len, Stream.length, ... There are some fields that never becomes greater than 32-bits (i.e. ACK block size).

We can try to have different types for based on each of the requirements. However that causes pain, because we cannot reuse code. That was the pain we had, until we introduced variable integers in #877.

I do not think we need to revert that to reopen tons of issues.

-- 
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/1577#issuecomment-406131483

---

From: ianswett <[email-masked]>
Date: Wed, 18 Jul 2018 19:43:18 -0700

I'd like to stick with the varint heavy design for QUIC v1.  If it turns out to be a pain in practice, let's reconsider for v2.

-- 
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/1577#issuecomment-406136809

---

From: Patrick McManus <[email-masked]>
Date: Thu, 19 Jul 2018 05:03:59 -0700

I agree with ian and kazuho, the current "mostly standard" use of varint is
better than big grab bag set of different sizes we had before

On Wed, Jul 18, 2018 at 10:43 PM, ianswett <[email-masked]> wrote:

> I'd like to stick with the varint heavy design for QUIC v1. If it turns
> out to be a pain in practice, let's reconsider for v2.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1577#issuecomment-406136809>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5s79wDMGBss4EJxQXokTYFcSpgs1Bks5uH_JEgaJpZM4VTFuj>
> .
>

-- 
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/1577#issuecomment-406252621

---

From: janaiyengar <[email-masked]>
Date: Mon, 30 Jul 2018 17:58:46 -0700

I don't have a strong opinion, but @kazuho's point is fair. 

Based on the feedback on this issue, I'm going to close it.  If you think we ought to continue discussing this point, please feel free to reopen.

-- 
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/1577#issuecomment-409059268

---

From: janaiyengar <[email-masked]>
Date: Mon, 30 Jul 2018 17:58:46 -0700

Closed #1577.

-- 
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/1577#event-1761564358