Subject: [quicwg/base-drafts] Swap largest reference and base indices (#1362)

From: Martin Thomson <[email-masked]>
Date: Sun, 20 May 2018 19:13:10 -0700

The value of the base index can be set at the start of an encoding pass.  Swapping the two values means only one change for the encoder when it comes back to update the header.

It also means less likelihood of a change in size.  If largest reference moves near (for example) 127, then its encoded size needs to change.  But it would be rare to find that the largest reference would differ from the base by more than 127 octets, even something an implementation could prevent.

The corner case here is where there are NO dynamic table references at all.  I found this to happen in tests occasionally.  This alternative design is no better in that regard because both values need to be set to 0 in that case.  Using a negative zero offset as a special case is a great idea, but the value exists.

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

---

From: afrind <[email-masked]>
Date: Tue, 22 May 2018 09:06:01 -0700

The reason Largest Reference comes first is that the decoder needs to examine this value first before knowing if it can even attempt to decode the block.  One can use scatter/gather i/o to handle the fact that the prefix values are need to be updated at the end of the encoding pass (eg: encode them in two different buffers, rather than messing around with the beginning of single buffer).

It's not clear to me what you mean by 'negative zero offset as a special case' - can you elaborate?

-- 
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/1362#issuecomment-391047807

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 May 2018 11:04:40 -0700

To save a day/night cycle, I read that as:

- The proposal is to encode LR relative to Base rather than the other way around, because LR will usually be +/-127 from Base all the time.
- When LR turns out to be zero and Base is >127, the suggestion is a sentinel value (negative zero) mean "actually zero" instead of "difference of zero."

-- 
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/1362#issuecomment-391086208

---

From: afrind <[email-masked]>
Date: Tue, 22 May 2018 13:39:51 -0700

Logically I prefer LR first - it's the first thing needed and the decoder only needs to read one variable length integer out of the transport instead of two.  It's the only value that needs to be updated after encoding (unsure why you said "Swapping the two values means only one change...").

With -0 you can get away without resizing the encoding of LR and shifting the buffer *most* of the time, but you'll still need code to handle the case where it does resize, and this code path will be rarely exercised, or worse -- omitted.  If we were going to special case -0 => LR=0, we should do this universally rather than only when Base > 127.

-- 
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/1362#issuecomment-391133033

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 May 2018 14:01:29 -0700

No, Martin's correct about that.  If Base is given as an absolute and LR as a delta, you only update one field (the delta) once you know LR.  If LR is given as an absolute and Base as a delta from that, you can't fill in *either* field until you know the value of LR.

-- 
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/1362#issuecomment-391139346

---

From: afrind <[email-masked]>
Date: Tue, 22 May 2018 14:45:00 -0700

Ah gotcha (I know Martin couldn't be wrong, what was I thinking?).  I guess my argument is that since you can't know the length of the prefix before you encode, it's not worth trying.  Can you help me understand the advantage of doing so?  Or the complications caused by writing the whole prefix at the end?

-- 
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/1362#issuecomment-391150923

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2018 19:35:30 -0700

I'm going to abandon this one.  We discussed it and decided that LR is better as the first.  It reduces the complexity of the blocking code by a smidge.  I'll change my 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/issues/1362#issuecomment-393011377

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2018 19:35:31 -0700

Closed #1362.

-- 
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/1362#event-1652523703