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 04:59:15 UTC