[quicwg/base-drafts] Boolean blocked streams setting (#3073)

[Bence Béky <[e-mail]>]

# Proposal

Replace the numerical limit SETTINGS_QPACK_BLOCKED_STREAMS on number of blocked
streams by a Boolean setting: if 0, the encoder MUST not send a header block
with Required Insert Count exceeding Known Insert Count and the decoder MUST
treat the receipt of such a header block as connection error.  If 1, the number
of blocked streams is not directly limited.

Given the necessary implementation complexity especially on the encoder side, I
do not believe that a numerical limit is worth its purported advantages.

# Pros

Determining the number of blocked streams has considerable computational
complexity on the encoding side.  While it is true that the encoder already has
to keep track of all unacknowledged header blocks, it takes extra work to count
the blocked ones.

One approach is to keep a count of blocked streams that needs to be updated
every time a header acknowledgement, an insert count increment, or a stream
cancellation instruction is received.  Examples include [nghttp3](https://github.com/ngtcp2/nghttp3/blob/master/lib/nghttp3_qpack.h#L239) and
[Quinn](https://github.com/djc/quinn/blob/master/quinn-h3/src/qpack/dynamic.rs#L337).

Another approach is to count blocked streams every time a new header list is
encoded to determine if it is allowed to use unacknowledged references, by
iterating through all unacknowledged header blocks at least until the limit is
reached.  An example is [QUICHE](https://quiche.googlesource.com/quiche/+/master/quic/core/qpack/qpack_blocking_manager.cc#74) (the Google one, not the Cloudflare one).

Both approaches are considerably complex and thus error-prone to implement.

The situation is further complicated by two factors.  The first is that there
can be multiple unacknowledged header blocks on each stream (in case of 1xx
status code or trailing headers).  The second is that if there is already a
potentially blocking unacknowledged header block on a given stream, then
referencing unacknowledged entries is always allowed in subsequent header blocks
on the same stream regardless of the limit.

This is one of the most complex requirements necessary to implement a blocking
QPACK encoder, raising concerns of potential implementation bugs that could
result in incorrect behavior, or vulnerability to CPU attacks due to buggy or
suboptimal algorithms.  Replacing the numerical limit with a Boolean would allow
the encoder implementation to be much simplified.

# Cons

The desire for a limit on blocked streams is articulated at
https://github.com/quicwg/base-drafts/issues/1140#issuecomment-371677474, and is
further motivated by flow control considerations.

The number of streams with blocked header blocks a is already limited by the
number of bidirectional streams the peer can open, set by the decoder using the
initial_max_streams_bidi transport parameter and the MAX_STREAMS frame.  Since
the total memory footprint of the objects representing a stream (including
transport functionalities like buffering, ordering, flow control, and
retransmissions) are not expected to be dominated by the footprint of the QPACK
decoder and buffered header block (not considering the buffered data itself in
either case), there is little additional value in selectively limiting the
number of streams blocked on header block decoding given that the number of open
streams is already limited.

As for the issue of a blocked header block taking up a large amount of the flow
control window, SETTINGS_QPACK_BLOCKED_STREAMS only addresses this concern if
the stream level flow control window multiplied by the blocked stream limit is
less than the connection level flow control window.  However, a typical decoder
is expected to set the blocked stream limit to either zero or at least a dozen,
and connection level flow control is typically only a few times larger than the
stream level flow control for performance reasons.

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