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

RE: #539: Priority from server to client

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 1 Jul 2014 16:37:49 +0000
To: Johnny Graettinger <jgraettinger@chromium.org>, Mike Bishop <Michael.Bishop@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532D786F2@ADELE.crf.canon.fr>
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, 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.

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/

> 
> 
> 
> 
> 
> 
> 
> 

Received on Tuesday, 1 July 2014 16:38:30 UTC

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