Subject: [quicwg/base-drafts] Offset bit in stream frame (#998)

From: martinduke <[email-masked]>
Date: Wed, 06 Dec 2017 17:37:17 -0800

With varints, we are the point where the offset bit is consuming several codepoints while saving the grand total of 1 byte per stream over the life of the connection. This seems profligate given that we got rid if the num-blocks flag in the ACK, which will usually save 1 byte per ACK.

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

---

From: martinduke <[email-masked]>
Date: Wed, 06 Dec 2017 17:37:46 -0800

I'm happy to file a PR if no one strongly objects.

-- 
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/998#issuecomment-349833828

---

From: ianswett <[email-masked]>
Date: Wed, 06 Dec 2017 19:03:59 -0800

This is actually saving 1 byte per stream, which if we're using lots of small streams, is a large-ish.  That being said, if we have a MESSAGE frame(Issue #814) that's optimized for sub-MTU payloads, maybe it doesn't matter.

So I'm a bit resistant at the moment, but could be convinced otherwise, especially if we have a MESSAGE frame or something similar.

-- 
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/998#issuecomment-349848596

---

From: MikkelFJ <[email-masked]>
Date: Thu, 07 Dec 2017 00:45:17 -0800

I'm in line with @ianswett here. I would strongly object unless an alternative solution is provided.

A very likely use case is to send lots of new stream frames for high speed signalling of unrelated short lived streams. You can have hundreds of streams in one MTU. Even a message frame that might not sort it out because each "message" or signal might occasionally be too long for one frame, or some of the streams turns out to not be as short-lived and more content will follow.

If anything, I would like the stream header more compressed, for example by storing stream ID's as deltas.

-- 
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/998#issuecomment-349901056

---

From: MikkelFJ <[email-masked]>
Date: Thu, 07 Dec 2017 00:52:39 -0800

If the type code space is tight, I would rather have a longer extension type for less frequently used 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/issues/998#issuecomment-349902749

---

From: Marten Seemann <[email-masked]>
Date: Thu, 07 Dec 2017 01:05:33 -0800

I don't think that saving frame type code points is something we need to aim for. Currently, we have plenty of space, and it seems unlikely that we'll add a significant number of new frames.
Since the frame type byte is version specific, we also don't need to be thrifty in order to be able to accommodate future changes.

If anything, I'd suggest that we go through all frames at some point, and see if we can save a byte here and there (for commonly used frames) by consuming more frame type code points.

-- 
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/998#issuecomment-349905819

---

From: martinduke <[email-masked]>
Date: Thu, 07 Dec 2017 15:50:13 +0000 (UTC)

I guess I was the only one gratified to see the ACK Frame "num blocks" flag to go away. I'll close this issue.

-- 
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/998#issuecomment-350008152

---

From: martinduke <[email-masked]>
Date: Thu, 07 Dec 2017 07:50:13 -0800

Closed #998.

-- 
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/998#event-1377172436