Re: Lost initial MAX_PUSH_ID is unfortunate

[Ian Swett <[e-mail]>]

I think max push ID in settings definitely makes sense if SETTINGS are in
the crypto handshake, but if we don't pursue that route, I think it ends up
being slightly more complex, because a MAX_PUSH_ID frame could arrive
before the corresponding setting.

On Thu, Aug 29, 2019 at 9:52 AM Ryan Hamilton <rch=
[e-mail]> wrote:

> On Wed, Aug 28, 2019 at 4:50 PM Martin Thomson <[e-mail]> wrote:
>
>> On Thu, Aug 29, 2019, at 04:39, Nick Harper wrote:
>> > Why can't we have the best of both worlds? If we put this signal in the
>> > crypto handshake, the application protocol can guarantee that it
>> > arrives before any STREAM frames, and we don't introduce any more head
>> > of line blocking because the connection is already blocked on the
>> > crypto handshake messages to derive 0-RTT or 1-RTT application data
>> > keys.
>>
>> You can already have that.  Coalescing the packet containing
>> SETTINGS/MAX_PUSH_ID with the last Handshake packet is entirely possible
>> and has the same net effect.  And most implementations will be able to
>> manage that (at least on the client side, coalescing 0.5RTT from the server
>> is a little challenging).
>>
>> But it's not best of both worlds, that would be forcing head of line
>> blocking.  Right now, implementations choose their level of exposure.
>>
>
> Yeah, coalescing SETTINGS/MAX_PUSH_ID along with the last handshake packet
> is definitely a possibility, and is the option I'm planning to pursue in
> our implementation if the proposal to put SETTINGS in Transport Params is
> really dead :) On the other hand if that proposal gains traction, I'd love
> to see an initial max push id setting.
>