Re: Lost initial MAX_PUSH_ID is unfortunate

[Ryan Hamilton <[e-mail]>]

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.