RE: #539: Priority from server to client

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