Draft: draft-ietf-quic-http

Commentary: As per HTTP MUST allow enough uni streams credits for mandatory streams ( control , QPACK encoder / decoder , other mandatory extensions ) but is not required to grant additional credits if the peer wastes them . This is the companion PR to updating the requirements in the HTTP draft , and together they I created a separate PR since it touches -http instead of -qpack , so it does n't get blocked by the QPACK refactoring . 
 It 's acceptable but not ideal . Did nt we just remove a mandatory TP in some unrelated change ? 
 Also rebased to fix conflict . 
 That is an exceptionally long sentence . But I think the text is correct . 
 Now that is being merged , we have the possibility to avoid creating unnecessary encoder / decoder streams . Avoiding creation is beneficial for memory - constrained devices , because they can configure the QUIC transport stack to handle at most one unidirectional stream ( in each direction ) to support HTTP/3 if the QPACK state forbids 1 ) peer 's creation of the encoder stream when endpoint 's is zero , and 2 ) peer 's creation of decoder stream is delayed until the endpoint 's creation of the encoder stream . With the proposed changes , a memory constrained HTTP/3 stack that sends of zero and never opens an encoder stream can be certain that the peer never opens an encoder stream or a decoder stream . Note that it has minimal impact to existing implementations ; regarding creation of the encoder stream , states that the stream can not be used until SETTINGS is being received . It is a clarification ( or a requirement ) that " use " includes the creation of the stream . The situation is the same for the decoder stream . Pull request filed as . 
 Discussed in Tokyo ; do not require creating the streams , but creating them is not forbidden even if the setting prevents their use . 
 And make sure that constrained devices can trivially detect and reset non - forbidden forbidden streams instead of assigning state . 
 I made to try and put into writing what was discussed in Tokyo since there has n't been any actiity in a while . Incidentally we run into the problem of allowing endpoints to create all QPACK control streams while interop'ing between quant and quiche HTTP/3 . 
 Discussed and clarified in London . MUST set initialmaxuni_streams to at least 3 does not have to keep granting more credit if the peer burns the stream credits on grease / push / extensions . SHOULD create control , qpack encoder and decoder as their first 3 streams if they plan to use them , since there 's no guarantee of ever getting more credit . 
 Created in addition to the existing PR to also update the -http requirements as per the discussion in London . 
 There 's one nit which implies a design question ; once that 's settled one way or another , I 'm happy with this .
Paragraph (version A):
The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on
unidirectional streams.  Endpoints that set low values for the QUIC
transport parameters "initial_max_uni_streams" and
"initial_max_stream_data_uni" will increase the chance that the
remote peer reaches the limit early and becomes blocked.  In
particular, the value chosen for "initial_max_uni_streams" should
consider that remote peers may wish to exercise reserved stream
behavior (stream-grease).  To reduce the likelihood of blocking, both
clients and servers SHOULD send a value of three or greater for the
QUIC transport parameter "initial_max_uni_streams", and a value of
1,024 or greater for the QUIC transport parameter
"initial_max_stream_data_uni".
Paragraph (version B):
The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on
unidirectional streams.  Endpoints that set low values for the QUIC
transport parameters "initial_max_uni_streams" and
"initial_max_stream_data_uni" will increase the chance that the
remote peer reaches the limit early and becomes blocked.  In
particular, the value chosen for "initial_max_uni_streams" should
consider that remote peers may wish to exercise reserved stream
behavior (stream-grease).  To avoid blocking, both clients and
servers MUST allow the peer to create at least one unidirectional
stream for the HTTP control stream plus the number of unidirectional
streams required by mandatory extensions (such as QPACK) by setting
an appropriate value for the QUIC transport parameter
"initial_max_uni_streams" (three being the minimum value required for
the base HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024
or greater for the QUIC transport parameter
"initial_max_stream_data_uni".
Paragraph (version B):
Note that an endpoint is not required to grant additional credits to
create more unidirectional streams if its peer consumes all the
initial credits before creating the critical unidirectional streams.
Endpoints SHOULD create the HTTP control stream as well as the
unidirectional streams required by mandatory extensions (such as the
QPACK encoder and decoder streams) first, and then create additional
streams as allowed by their peer.