RE: #539: Priority from server to client

I still think that it's useful for the server to inform the client on how it intent to order its pushed streams. Amos gave a good example of how it could be used in http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0856.html.

At the same time, I understand that using the PRIORITY frame for this may not be the best way to do this, as the semantic of the PRIORITY would not be the same depending on the sender's role.

We could have a twofold outcome:
1. We use option (2) for the meaning of a PRIORITY frame sent from the server to the client.
2. We allow the server to express its priority intentions concerning pushed streams. We could add new optional priority fields to the PUSH_PROMISE frame, that would convey the server intent.

Hervé.

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: mardi 15 juillet 2014 06:59
> To: RUELLAN Herve
> Cc: Mike Bishop; HTTP Working Group; Johnny Graettinger
> Subject: Re: #539: Priority from server to client
> 
> We don't seem to be converging on an outcome here.
> 
> Herve, do you still want to pursue this? If we take one of the existing options,
> (2) currently seems most likely.
> 
> I think option (4) is to leave it undefined...
> 
> 
> On 2 Jul 2014, at 4:01 am, Johnny Graettinger <jgraettinger@chromium.org>
> wrote:
> 
> > On Tue, Jul 1, 2014 at 12:37 PM, RUELLAN Herve
> <Herve.Ruellan@crf.canon.fr> wrote:
> > I'm interested in 1).
> >
> > When using DASH, a server can push several video fragments to the client.
> These video fragments should be pushed one after the other in their viewing
> order. A smart server will do this,
> >
> > Makes sense, it seems reasonable to me that a server would want to initialize
> push priorities in this way, and assuming that clients abstain from sending
> PRIORITY for push-streams they haven't yet discovered a need for, it sounds
> like it could provide a benefit. I'm disagreeing only with the utility of
> advertisement.
> >
> >
> > and should have a way to inform the client, otherwise the client will need to
> send re-prioritization to ensure the server does the right thing.
> >
> >
> > For this to be useful, it pre-supposes a client who has an opinion about
> priority, and disagrees with the server's prioritization, yet is willing to be over-
> ruled by the server's prioritization anyway. Such a client seems unlikely to me
> (how would it reconcile the differing prioriziations?).
> >
> > Otherwise, we're just talking about saving a PRIORITY frame if the client
> happens to find it agrees with the server's advertisements, which doesn't seem
> like a required optimization.
> >
> >
> > There is a possible race with a client-sent PRIORITY. It could be solved by
> ruling that the client PRIORITY takes precedence over the server PRIORITY.
> >
> > Hervé.
> >
> > > -----Original Message-----
> > > From: jgraettinger@google.com [mailto:jgraettinger@google.com] On
> Behalf
> > > Of Johnny Graettinger
> > > Sent: mardi 1 juillet 2014 18:23
> > > To: Mike Bishop
> > > Cc: Mark Nottingham; HTTP Working Group
> > > Subject: Re: #539: Priority from server to client
> > >
> > > 2) makes sense to me.
> > >
> > > I don't think I understand the value of a server advertising to the client what
> > > priority it's using to send a push-stream. By construction, at this point the
> client
> > > hasn't yet integrated the stream into it's resource loading flow, and can't
> make
> > > any prioritization decision. As soon as the client discovers it's need for the
> > > resource, that would be an appropriate time for it to send a PRIORITY to the
> > > server anyway.
> > >
> > > Also, nothing prevents a client POST from depending on a server push
> stream.
> > > In this case, a server-sent PRIORITY on that push stream already has
> another
> > > meaning (it implicitly re-prioritizes the POST stream).
> > >
> > > There may be value in relaxing the language in "5.3.5 Default Priorities" to
> > > allow the server to assign an arbitrary initial weight (eg, because it has
> > > knowledge the client doesn't yet have about load priority).
> > >
> > >
> > > On Tue, Jul 1, 2014 at 10:27 AM, Mike Bishop
> > > <Michael.Bishop@microsoft.com> wrote:
> > >
> > >
> > >       Hervé is correct that the spec currently under-defines what it means
> > > when a PRIORITY frame goes from server to client.  However, there are a
> > > couple different options for what it might mean:
> > >         1) Server declares the priority it has placed on a stream.
> > >               + What if it's racing with a client-sent PRIORITY frame?
> > >         2) Server informing the client how the client ought to allocate
> > > resources
> > >               + Really only makes sense if the client has multiple large
> > > PUT/POSTs going on
> > >         3) Server can't send these.
> > >
> > >       In NYC, we closed a related issue of having the server send its initial
> > > priority in the PUSH_PROMISE.  If we picked the first, that would be a
> natural
> > > corollary to the optional presence of PRIORITY in the HEADERS frame.
> > >
> > >       I do think we should define one, just so there aren't different semantics
> > > on both sides of the connection.  I agree that the first makes me itch
> slightly.
> > >
> > >
> > >       -----Original Message-----
> > >       From: Mark Nottingham [mailto:mnot@mnot.net]
> > >       Sent: Tuesday, July 1, 2014 12:09 AM
> > >       To: HTTP Working Group
> > >       Subject: #539: Priority from server to client
> > >
> > >       <https://github.com/http2/http2-spec/issues/539>
> > >
> > >       I thought we'd discussed this a bit in NYC, but don't see anything in the
> > > minutes.
> > >
> > >       How do people feel about this? Herve has made a proposal in a pull
> > > request:
> > >         <https://github.com/http2/http2-spec/pull/526/files>
> > >
> > >       Personally, my .02 - I get nervous when a protocol element has
> > > different semantics depending on what direction it's travelling; e.g., Cache-
> > > Control turned out to be very confusing. It feels like that's going on here
> too; in
> > > one direction, it's a priority request, whereas in the other it seems like a
> > > declaration...
> > >
> > >       Cheers,
> > >
> > >
> > >       --
> > >       Mark Nottingham   https://www.mnot.net/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
>

Received on Tuesday, 15 July 2014 16:42:30 UTC