Subject: [quicwg/base-drafts] Benefit of variable-length fields? (#40)

From: Lars Eggert <[email-masked]>
Date: Mon, 28 Nov 2016 00:31:53 -0800

Packet numbers, stream offsets, various ACK information and many other fields can currently be encoded as variable length. Do we have some data on the benefits of this complexity? Would it be sufficient to use fewer increments, or could we even move to fixed length encoding for some or all of these fields?

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

---

From: MikeBishop <[email-masked]>
Date: Tue, 29 Nov 2016 13:36:52 -0800

Anecdotally, Christian's implementation experience was that it wasn't that hard to implement and did save a noticeable amount of packet overhead.  I presume the Google folks have similar experience and possibly numbers.

If we find that we can use a particular length most of the time, it might be reasonable to simplify to *only* that length and full-length, though.  I agree that having so many options can be 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/issues/40#issuecomment-263706721

---

From: ianswett <[email-masked]>
Date: Tue, 29 Nov 2016 13:55:40 -0800

We don't have any quantitative performance data I'm aware of.  In the case
of acks, where before we did variably sized packet numbers, acks could
consume an entire packet, which caused lots of problems, not just a latency
hit.  But that was early on, and I don't have good numbers for the impact
of that.  I will say that there are cost benefits to saving 1-2% of
internet bandwidth which may be more important than a small change in
latency.

The only case that ends up being complex to implement in our experience is
the variable packet number length.  That's complex because if you
retransmit a packet with a longer packet number length, it may suddenly be
too large for the path, and be consistently dropped, so you have to save
the original packet length for retransmissions.  In that case, I can
imagine a connection negotiating a single length and using it the entire
time, but the current approach allows a fixed size for the sender without
negotiation, so it seems simpler overall.

Some simplification may be possible, but we've already simplified the easy
cases, such as only allowing 0 or 8 byte connection ids(before there were 4
lengths).

I will note the ability to send a 6 byte packet number instead of an 8 byte
one is silly, and we should just do 1, 2, 4 and 8.

On Tue, Nov 29, 2016 at 4:36 PM, MikeBishop <[email-masked]>
wrote:

> Anecdotally, Christian's implementation experience was that it wasn't that
> hard to implement and did save a noticeable amount of packet overhead. I
> presume the Google folks have similar experience and possibly numbers.
>
> If we find that we can use a particular length most of the time, it might
> be reasonable to simplify to *only* that length and full-length, though.
> I agree that having so many options can be confusing.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/40#issuecomment-263706721>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJcWiYdtGsE-hGL8lUTPadIWiTbfDAks5rDJr0gaJpZM4K9hGj>
> .
>

-- 
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/40#issuecomment-263712083