Subject: [quicwg/base-drafts] [QPACK] Appendix B.5 seems violating eviction policy (#4935)

From: Daiki AMINAKA <[email-masked]>
Date: Thu, 19 Aug 2021 21:38:31 -0700

B.5 evicts `:authority  www.example.com` at absolute index 0 which is referenced by duplicated entry at absolute index of 3 which is acknowledged.
Based on section 2.1.1, entry is not evictable if it is referenced by unacknowledged entry.
Is my understanding correct?

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 20 Aug 2021 10:30:35 -0700

>From [Section 2.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#name-limits-on-dynamic-table-ins):
> Note that references on the encoder stream never preclude the eviction of an entry, because those references are guaranteed to be processed before the instruction evicting the entry.

There are no outstanding references to absolute index 0 (or any other table entry) in encoded field sections.

-- 
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/4935#issuecomment-902846780

---

From: Daiki AMINAKA <[email-masked]>
Date: Fri, 20 Aug 2021 22:11:21 -0700

What does this `outstanding reference` mean in this context?

-- 
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/4935#issuecomment-903060143

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Aug 2021 08:19:06 -0700

All encoded field sections which reference absolute index 0 have been acknowledged; the only one of these shown occurs in B.2 and is acknowledged in the same example.  The insertion of absolute index 0 has been acknowledged; also in B.2, since the section that referenced it was processed.  Therefore, the entry is evictable.

-- 
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/4935#issuecomment-903868322

---

From: Daiki AMINAKA <[email-masked]>
Date: Mon, 23 Aug 2021 23:51:47 -0700

1. I misunderstood the `reference` means reference from duplicated entry (or entry which refers only field name) against an entry in dynamic table. e.g. B.4's abs 3 refers abs 0.
2. Then eviction must not happen during referencing entries if encoder instructions arrive in appropriate order (e.g. send referenced headers -> insert headers (-> evict non-referenced header))
3. However these instructions arrives in expected order...? Sorry, I'm not familiar with stream level packet ordering.

Out of topic
Why don't we explain `outstanding`  more clearly? it is not explained in RFC and you do not explain.
Anyone cannot explain means that it is vague

-- 
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/4935#issuecomment-904371103

---

From: Mike Bishop <[email-masked]>
Date: Tue, 24 Aug 2021 06:47:57 -0700

Everything on a stream is processed in order; the packets might arrive out-of-order, but QUIC will present a sequential bytestream to the application layer (QPACK in this case).  So within one stream, we can guarantee that no later instruction will be processed before an earlier instruction.  That means that whatever the state of the table was at the encoder when an instruction was generated, you can be sure that's the state at the decoder when the instruction is consumed.

-- 
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/4935#issuecomment-904658337

---

From: Daiki AMINAKA <[email-masked]>
Date: Tue, 24 Aug 2021 23:58:04 -0700

Thanks for clarification.
Maybe the point is how many streams QUIC can establish (Sorry this would be out of this topic)

>From Section 4.2
> Each endpoint MUST initiate at most one encoder stream and at most one decoder stream

Yes, field sections and instructions should arrive in expected order from this sentence, because there is single encoder stream.
But From Section 2.1.2
> Because QUIC does not guarantee order between data on different streams, a decoder might encounter a representation that references a dynamic table entry that it has not yet received.

This implicitly means QUIC establishes multiple encoder streams then blocked one of streams if condition matches.
Moreover From Section 2.2
> Note that encoded field sections and encoder stream instructions arrive on separate streams

This also means QPACK allows to establish multiple encoder streams. 
How many stream QUIC can handle? some sentences are not correct?

-- 
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/4935#issuecomment-905235536

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Aug 2021 06:44:56 -0700

> This implicitly means QUIC establishes multiple encoder streams then blocked one of streams if condition matches.

No -- representations are in encoded field sections, which arrive on request and push streams.  Those are separate from encoder streams, as noted in the text you quoted next.

QPACK cannot establish multiple encoder streams in a given direction.  On a connection, there are:

- one encoder stream in each direction
- one decoder stream in each direction
- up to the number of request streams the server chooses to allow
- up to the number of push streams the client chooses to allow

QUIC itself imposes no limit on the number of simultaneous request or push streams, but allows the endpoints to communicate and enforce their own limits.

-- 
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/4935#issuecomment-906427410

---

From: Daiki AMINAKA <[email-masked]>
Date: Tue, 31 Aug 2021 07:27:33 +0000 (UTC)

> 4.5. Field Line Representations
> An encoded field section consists of a prefix and a possibly empty sequence of representations defined in this section. Each representation corresponds to a single field line. These representations reference the static table or the dynamic table in a particular state, but do not modify that state.
> 
> Encoded field sections are carried in frames on streams defined by the enclosing protocol.

You are right, encoded field sections are carried on request/push streams. Thanks!

Then I guess steps bellows would become issue (should I create another issue or change title?)
1. send encoded field section which refers entry at abs 0 from dynamic table
2. send Set Dynamic Table Capacity instruction which evicts entry at abs 0 from dynamic table. evict entries from encoder's dynamic table
3. 2. arrives earlier than 1. (because different streams). evict entries from decoder's dynamic table
4. 1. arrives, but referenced entry (abs 0) was already evicted
I know draining index feature could avoid referencing about-to-evict entry, but it is not MUST feature.

-- 
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/4935#issuecomment-908973304

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Aug 2021 00:39:55 -0700

An encoder is responsible for ensuring that any entry that it might cause to be evicted (by inserting, duplicating, or resizing) only occurs after all references to that entry have been acknowledged by the decoder.  That is why we have a decoder stream with acknowledgments.

In this case, if you have not received an acknowledgment (or a cancellation for the stream that contained the reference) you can't resize the dynamic table.

-- 
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/4935#issuecomment-908980833