Re: #539: Priority from server to client

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/
> >
> >
> >
> >
> >
> >
> >
> >
>
>