Re: Consistency in Stream Beginnings in HTTP/3

Of the options, I'd personally prefer revisiting #2526 and making push ID a
required first frame on a push stream.

On Thu, Jun 13, 2019 at 11:47 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Thanks for summarising all of this individual discussions Mike.
>
> I have a derivative design on the SETTINGS stream header which would
> replace length-prefix with count. So rather than Express total length of
> parameter ID and value, you tell the receiver how many variant pairs to
> process before processing frames.
>
> I dont think that strongly pushes the needle in one direction though.
>
> If we reject changing the control stream, I'm presently 50/50 split
> between revisiting push stream framing and just living with what we have.
>
>
> On Thu, 13 Jun 2019, 18:30 Mike Bishop, <mbishop@evequefou.be> wrote:
>
>> This discussion has happened across a collection of GitHub issues with
>> largely the same participants, and I’d like to get a sense of the larger
>> working group’s opinion before I work on any of these directions (or close
>> all the related issues).
>>
>>
>>
>> To recap the current state:
>>
>>    - Unidirectional streams begin with a type byte; interpretation of
>>    the remainder of the stream data depends on the type
>>    - Push streams continue with a header – the Push ID as a varint –
>>    followed by frames as usual
>>    - Control streams don’t have a header; frames begin immediately after
>>    the type byte.  However, a SETTINGS frame is required to be the first frame
>>    of the stream.
>>    - SETTINGS cannot be sent again thereafter or on any other stream
>>
>>
>>
>> That means there are currently two different models of how you put
>> required-to-be-first information:  As a required-initial frame or as a
>> header before framing begins.
>>
>>
>>
>> There are a couple of paths forward that have been discussed:
>>
>>    - *Stay as-is.*  SETTINGS is a frame in HTTP/2, so we’re keeping it
>>    that way for consistency.  We’ve previously decided not to permit changes
>>    to settings to avoid the question of synchronization.  The reasons to
>>    change are not urgent.
>>    - *Make the Push ID a required-initial frame.  *Proposed in #2526;
>>    rejected in London.
>>    - *Make SETTINGS a stream header.*  Proposed in #2783.
>>       - *Argument for:*  Gets rid of the concept of required-initial
>>       frames, in combination with #2781.  Consistent with the Push Stream header.
>>       - *Argument against:*  Push ID isn’t a length-prefixed structure,
>>       just a single varint.  We already have facilities for reading
>>       length-prefixed structures in frame handling.
>>    - *Allow multiple SETTINGS.*  The synchronization requirement on
>>    SETTINGS is hairy when values are reduced, because in-flight activity might
>>    now violate a peer’s restriction.  Allowing SETTINGS to be sent at any
>>    time, but only increase values, would also mean they need not be the first
>>    frame, eliminating the concept of required-initial frames.
>>       - Complication:  What does this mean for clients’ remembered
>>       settings and server’s remembered settings as stored in NSTs?  If a client
>>       updates stored settings but retains a NST from earlier in the connection,
>>       the server and client could have divergent views of the server’s settings
>>       on a future 0-RTT connection.
>>    - *Allow omitting SETTINGS.*  If the server doesn’t need to change
>>    anything from the client’s initial settings, then the server can just not
>>    send a SETTINGS frame.  Once you’ve sent something else on the control
>>    stream, though, you can’t send one later if you change your mind.
>>
>>
>>
>> Thoughts?
>>
>