Re: Lost initial MAX_PUSH_ID is unfortunate

[Nick Harper <[e-mail]>]

On Tue, Aug 27, 2019 at 8:00 PM Martin Thomson <[e-mail]> wrote:

> On Wed, Aug 28, 2019, at 08:48, Ryan Hamilton wrote:
> > In some testing we've been doing, we realized that if the packet
> > containing the initial MAX_PUSH_ID frame is lost (or reordered until
> > after the first request) then the server is unable to push responses.
> > This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID
> > with all packets that send a new request until the MAX_PUSH_ID is
> > ACK'd. This feels a tad inelegant and I wondered if there's any
> > appetite for an alternative.
>
> I don't think that this is great justification for that sort of change.
> We explicitly removed head of line blocking from the processing of
> SETTINGS.  In practice, I suspect that this situation also results in no
> access to QPACK also.
>
> Performance might suffer, but at least you can send something sensible in
> a round trip when you would otherwise (with h2 for instance) be twiddling
> thumbs.
>
> 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.