W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #539: Priority from server to client

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 15 Jul 2014 14:58:45 +1000
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>, Johnny Graettinger <jgraettinger@chromium.org>
Message-Id: <302B3DF9-09DA-4C97-BF44-51CC2714EE86@mnot.net>
To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC