Subject: [quicwg/base-drafts] The 32 octet overhead (#1127)

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Feb 2018 19:13:59 -0800

The draft currently notes that the 32 octet per-record overhead that HPACK uses for accounting might need re-evaluation.

Having implemented QCRAM, per-record overheads didn't change for a decoder, so I would say that the 32 octet value is fine.  If this is OK, we should still track the fact that the issue was raised and discussed.  If not, this is a great place to air concerns.  For instance, maybe the HPACK overhead was wrong in some critical way, but I've not heard anyone suggest that.

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

---

From: afrind <[email-masked]>
Date: Wed, 21 Feb 2018 17:16:30 +0000 (UTC)

The encoder needs to track more things than it did before for the same size decoder table.  Of course, that's entirely the encoder's problem, and the encoder can choose to use fewer table entries to compensate.

-- 
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/1127#issuecomment-367400981

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Feb 2018 23:32:50 +0000 (UTC)

Yes, the encoder can track significantly more than a 32 octet overhead, but, as you say, that's entirely at their discretion, so I think that's fine.

-- 
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/1127#issuecomment-367514834

---

From: Mike Bishop <[email-masked]>
Date: Sun, 25 Feb 2018 07:13:44 -0800

Encoder can track as much or as little as it wants.  IIRC, the idea was that you need a pointer and length each for name and value.  An eight-octet length for an HPACK entry seems a little extreme, but platform-standard types....

-- 
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/1127#issuecomment-368317108

---

From: afrind <[email-masked]>
Date: Mon, 26 Feb 2018 17:02:57 +0000 (UTC)

I'm going to close this for now.  32 seems adequate for the decoder and matches HPACK.

-- 
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/1127#issuecomment-368572704

---

From: afrind <[email-masked]>
Date: Mon, 26 Feb 2018 17:04:52 +0000 (UTC)

Closed #1127.

-- 
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/1127#event-1492501234

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Feb 2018 16:51:31 -0800

Reopened #1127.

-- 
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/1127#event-1493331008

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Feb 2018 00:51:31 +0000 (UTC)

Re-opening as editorial -- if we've decided that 32 is fine, we need to remove the text from the draft that says it's not.

-- 
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/1127#issuecomment-368706315