Re: [quicwg/base-drafts] Consider making h3 frame types varint (#2253)

[Kazuho Oku <[e-mail]>]

No, I was imprecise in my last sentence.

What I was trying to clarify is that it is a requirement of H3 that a server cannot start sending frames on a *push stream* before it receives a MAX_PUSH_ID frame from the client, which arrives after SETTINGS. Therefore, any use of an extended frame on the *push stream* can be negotiated.

*Unidirectional streams* other than the push stream are not restricted to the frame definition of H3, so we have the room to do whatever we want, regardless of if we have varint frame types in H3.

The only case a server might want to send extended frames before seeing SETTINGS is when the client's request arrives before the SETTINGS frame due to packet loss or out-of-order delivery (I haven't considered this case before; please forgive me if you assumed this case).

But if we do care about such case (i.e. using 0.5 RTT or SETTINGS being delivered later), I think we should revisit the discussion of if we should use Transport Parameters for sending H3 settings. We would have the following benefit by exchanging H3 settings using Transport Parameters, :
* QPACK dynamic table can always be used; there is no need to operate in restricted mode until receiving SETTINGS from the peer
* Use of 0.5-RTT push (or any other extension) can be negotiated. That avoids wasting the bandwidth by sending extensions that the client does not understand.

-- 
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/2253#issuecomment-450622014