Sequential and Max Push ID (was Re: Push ID - Merge Imminent)

I think it's useful to avoid HoLB since the first request and the
MAX_PUSH_ID frame may get reordered and/or the MAX_PUSH_ID frame may need
retransmission. Push is already weak on benefits, so (without any evidence)
I wonder whether any benefits due to it would be sensitive to this small
variation.

That said, this isn't a strong opinion, so I'm not going to argue for it.

- jana

On Wed, Aug 9, 2017 at 9:15 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> Agreed that the SETTINGS entry and the frame are the same 5-8 bytes
> consumed, and it would be simpler to have a single code path.  Since this
> whole thing is a departure from HTTP/2, I’m not personally upset about
> diverging a little further in the name of simpler code.  This isn’t a value
> that either party needs to know before sending traffic to behave properly,
> which is the case with QUIC’s limits of this type that have the dual
> parameter/frame structure.
>
>
>
> *From:* Martin Thomson [mailto:martin.thomson@gmail.com]
> *Sent:* Tuesday, August 8, 2017 5:45 PM
> *To:* Jana Iyengar <jri@google.com>
> *Cc:* Ian Swett <ianswett@google.com>; Kazuho Oku <kazuhooku@gmail.com>;
> QUIC WG <quic@ietf.org>; ietf-http-wg@w3.org; Mike Bishop <
> Michael.Bishop@microsoft.com>
> *Subject:* Re: Push ID - Merge Imminent
>
>
>
> Just to follow up on this, I've opened https://github.com/quicwg/
> base-drafts/pull/711
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F711&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Ce79ff894e53147e720b208d4debfe880%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636378363209427335&sdata=4Ln%2Fu8AIWLTpnKdEDysMC6D6LWhlec0j0ISFCjOWHuo%3D&reserved=0>
>
>
>
> It defines a new frame type that sets the limit to Push ID.  In a fit of
> inspiration, I called it MAX_PUSH_ID.
>
>
>
> I have repurposed SETTINGS_ENABLE_PUSH for setting the initial limit.  The
> newly renamed SETTINGS_MAX_PUSH_ID sets the initial MAX_PUSH_ID.
>
>
>
> I want to discuss whether we might remove the setting.  Sending
> MAX_PUSH_ID immediately after SETTINGS doesn't add any more bytes and I'm
> not sure that there is any particular need to optimize for HoLB here.  I'm
> ambivalent, so I kept it, but it is easy to remove.
>
>
>
>
>
> On 5 August 2017 at 10:55, Jana Iyengar <jri@google.com> wrote:
>
> Martin,
>
>
>
> I think the idea of sequential Push ID is a good one. You have to specify
> a MAX_PUSH_ID, without which the client won't know how far out to expect
> CANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE
> message which can be used to move the MAX up.
>
>
>
> One note:
>
>
>
> PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the
> server. The text currently says that CANCEL_PUSH on a non-existent Push ID
> results in error, which does not work with the possibility of reordering
> between PUSH_PROMISE and CANCEL_PUSH.
>
>
>
> That's just a bug.
>
>
>
> I don't think so. The spec allows it, and I can easily see it happen in
> practice.
>
>
>
> - jana
>
>
>
>
>
> Similarly, it's also possible for the PUSH_PROMISE to not have been
> received because the stream on which it was sent was reset... basically
> it's possible for a client to receive a CANCEL_PUSH without seeing the
> corresponding PUSH_PROMISE.
>
>
>
> This is more interesting.  It creates state on the client:  it says that
> clients are required to ignore pushes that it *might* receive in the
> future.  That suggests a different fix, akin to what we use for other
> similar pieces of state:
>
>
>
> 1. make Push ID sequential (right now the only requirement is for
> connection-wide uniqueness)
>
>
>
> I think that using a sequential ID will be a good idea not only for fixing
> this issue but that it might be possible to use the sequentiality to fix
> the first issue raised in the PR (i.e. client knowing "when the server will
> stop referencing a push ID in PUSH_PROMISE").
>
>
>
> If there is a sequential ordering guarantee for Push ID, a client can, by
> looking at the Push ID, determine whether if it has already consumed the
> pushed request. If it has, it will immediately lookup its cache, and in
> case it fails to find a cached object, then issue a pull. If it has not
> consumed the pushed request, it should wait for the pushed response to
> arrive.
>
>
>
>
>
>
>
> 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new
> frame type; the setting might {ab|re}use ENABLE_PUSH)
>
>
>
> This would bound state for clients.  A client couldn't receive an
> arbitrary number of CANCEL_PUSH messages that are distributed over the
> 32-bit Push ID space, so tracking cancellations is easy.  Clients could use
> a simple bitvector to track which pushes are potentially interesting,
> clearing bits as pushes or cancellations arrive.
>
>
>
> MAX_PUSH_ID would give clients a finer-grained lever to control push.
>
>
>
> We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE,
> but that doesn't help with the case where the PUSH_PROMISE may not have
> been received due to a stream reset.
>
>
>
> This makes me wonder if it makes sense to always send the PUSH_PROMISE on
> the control stream *in addition to* any stream that it is sent on. This
> would ensure that no matter what, the PUSH_PROMISE is always received, and
> additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE.
>
>
>
> I don't think that is a good idea.  PUSH_PROMISE includes a headers block,
> which is pretty big, even with effective compression.  HoLB won't affect
> this stream, so size shouldn't be an issue, but still.
>
>
>
> I did consider moving the header block to the control stream completely as
> part of addressing the issue with duplication that I mentioned earlier.
> The basic problem there is that you don't guarantee that the client see the
> PUSH_PROMISE before it processes the response content.
>
>
>
>
>
> - jana
>
>
>
> On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop <Michael.Bishop@microsoft.com>
> wrote:
>
> Bah, QUIC too.  😊
>
>
>
> *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com]
> *Sent:* Thursday, August 3, 2017 10:36 AM
> *To:* ietf-http-wg@w3.org
> *Subject:* Push ID - Merge Imminent
>
>
>
> This is Martin’s Push ID PR split off from unidirectional.  Given that it
> has already been picked over in those contexts and the feedback from that
> and in-person discussion was to bring this change in separately, I’m about
> ready to merge this.  Everything anyone has quibbled with has been
> editorial.  However, I don’t see reviews from many folks, so I want to make
> sure that everyone interested has had a chance to express an opinion.
>
>
>
> https://github.com/quicwg/base-drafts/pull/701
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F701&data=04%7C01%7CMichael.Bishop%40microsoft.com%7C8c68a743428c43fd9e9508d4da9692a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636373787673436338%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIifQ%3D%3D%7C-1&sdata=lF5Cr5Fe1RuY5BOvPgiy9iaGqHS27%2B7jeM1IOipSxu4%3D&reserved=0>
>
>
>
> I’ll give it a few hours (until everyone’s had at least a little bit of a
> work day), then merge unless I hear otherwise.
>
>
>
>
>
>
>
>
> --
>
> Kazuho Oku
>
>
>
>
>
>
>