Re: [quicwg/base-drafts] Asymmetry in the handling of SETTINGS frame (#1846)

[Kazuho Oku <[e-mail]>]

@MikeBishop Yes. That is precisely the model I am interested in having. I also agree with your observation stated in the last paragraph.

I think I might rephrase my question to: why don't we block the client from sending *anything* until it receives SETTINGS, rather than just blocking the requests?

The benefits are:
* We can have offer-select semantics.
* We have the chance of reducing the number of unidirectional streams:
  * We might want to state that an endpoint opens a QPACK encoder stream only when it sees the peer advertising a non-zero table size, and that an endpoint opens a QPACK decoder stream only when it sees the peer opening the encoder stream. This would be a natural if we block the client from sending anything until it sees SETTINGS.
  * Then, a memory-constrained device would need to have only one slot for unidirectional streams in each direction, assuming that it advertises a QPACK table size of zero. This is better than the current requirement which requires us of having slots for three incoming unidirectional streams even though they might become idle.
* Expanding on the previous point, we even have the freedom to replace QPACK with something else; for example, we could have XPACK that uses a unidirectional stream identifier of 'X'.

Compared to these benefits, I do not see any downside in particular.

-- 
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/1846#issuecomment-428417336