Re: [quicwg/base-drafts] create codec streams only when necessary (#2090)

[Kazuho Oku <[e-mail]>]

@afrind 
> Per @kazuho's original problem statement:
> 
>> Avoiding creation them is beneficial for memory-constrained devices, because they can configure the QUIC transport stack to handle at most one unidirectional stream
> 
> Is anyone actually building a memory constrained implementation that would like to weigh in here? It strikes me as pretty simple to just receive a qpack unidirectional stream and discard it, or as @lnicco suggests, reset it.

Admittedly, I referred to the case of memory-constrained devices. However by reading the comments, I start to wonder if that is the only use-case that would suffer from the unnecessary creation of QPACK codec streams.

IIUC, the argument against mandating the lazy creation of QPACK codec streams is that the codec streams are very likely to be used, and that we should optimize for the majority. The logic itself sounds fine, but it's based on the premise that QPACK would be used for the entire lifetime of H3. If we are to start using an alternative to QPACK together with H3, every one of us would be handling the creation of QPACK codec streams that are useless.

H3 is the HTTP binding for the first non-TCP transport that is going to see lots of HTTP traffic. Considering how long we've been using TCP, it would be natural to assume (or hope) that H3's lifetime would span over multiple decades.

Compared to that, QPACK's lifetime might be shorter. It's not due to an issue in QPACK, but it's due to what's being compressed might change. The HTTP Working Group is working on [Structured Headers](https://tools.ietf.org/html/draft-ietf-httpbis-header-structure), that introduces structs and typed elements to the header fields. That changes how things can be compressed. Instead of compressing each header field, I'd assume that we'd be compressing each element of the header field (e.g., `stale-while-revalidate=YYY` would have it's own entry). We'd be compressing not only strings but also integers, booleans.

Should we be confined to develop the compression method for Structured Headers (and other changes that we might want to make in the future) as an extension to QPACK? I do not think we have enough information to make that decision.

To summarize, eager creation of QPACK codec streams could become unnecessary complexity not only for memory-constrained endpoints but for other endpoints as well. And I do not see why we need to ossify H3 in that way, considering the fact that the draft nevertheless requires endpoints to change the QPACK codec state when they receive SETTINGS (see [Mike's comment](
https://github.com/quicwg/base-drafts/pull/2090#pullrequestreview-181408669))

-- 
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/pull/2090#issuecomment-448758145