Subject: Nit: Server-sent priority

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2013 15:42:34 -0700

We discussed the possibility that a server could send PRIORITY (either
in its own frame or attached to HEADERS).  The idea was that the
server could advise a client about the priority that it is applying,
which might be different to the priority that a client requested.

This adds a challenge for clients: does the client now provide updated
priorities that are relative to the priorities that it sent
previously, or relative to the priority that the server has indicated?

e.g., client sends three requests, priority 7, 10 and 15.  Server
responds and indicates priorities of 3, 5 and 7.  If the client wants
to issue a new request that is higher priority than the lowest
priority existing request, does it indicate a priority of between 10
and 15?  Or does it indicate a priority of 6?

This editor wants to know.  I think that the easiest approach would be
to stipulate that the priorities spaces are independent and that
client priorities are only relative to client priorities.
Unfortunately, that means that I need to include the example above as
well.

I don't want to prohibit servers from sending priority, because I
believe that it could be useful for a client to understand how
priority is being applied.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 16:15:01 -0700

how about something like:
A client must not respond request a change in priority for a stream purely
on the basis of receiving a server priority announcement on that stream,
except when the client has never attempted to set a priority for that stream

-=R

---

From: James M Snell <[email-masked]>
Date: Tue, 18 Jun 2013 17:36:03 -0700

Editor Hat On...

Hmm.. can you take another pass at that... as written it's not very clear.

Implementer Hat On...

This is a tricky one that could end up causing an interesting race
condition (where the server and client compete on setting the highest
relative priority). At the interim, there was a general agreement that
server-send priority would be advisory only. Looking at it further
(and looking at it as an implementer) I'm not sure if that's going to
be quite enough.

Proposal: The priority is advisory in both directions. It tells the
receiving endpoint what priority the sending endpoint has given to the
stream but does not force the receiving endpoint to do anything. A
well behaved receiving endpoint will set it's priority to match, but
it might not do so... In other words:

Example:

A initiates Stream #1 to B, specifies PRIORITY=10
B responds to A, specifies PRIORITY=10... best case scenario, A and B
each agree on the priority

Example:

A initiates Stream #1 to B, specifies PRIORITY=10
B responds to A, specifies PRIORITY=15... not ideal, B is telling A
that it is treating Stream #1 with lower priority than A wanted.

Example:

A initiates Stream #1 to B, specifies PRIORITY=10
B responds to A, specifies PRIORITY=5... B is telling A that it is
treating Stream #1 with higher priority than A wanted.

Example:

A initiates Stream #1 to B, specifies PRIORITY=10
B responds to A, does not specify a priority... B is implicitly
telling A that PRIORITY=10 is an acceptable default.

Example:

A initiates Stream #1 to B, does not specify a priority... default
priority is assumed
B responds to A, specifies PRIORITY=10... B is telling A that it's not
going to use the default

Using this approach, each endpoint specifies PRIORITY only relative to
it's own view of each stream, regardless of whatever the other
endpoint has sent. Endpoints are encouraged to agree on PRIORITY for
each stream direction, but are not compelled to do so, allowing each
endpoint to decide for itself which is best in its specific case.

- James

---

From: Mike Belshe <[email-masked]>
Date: Wed, 19 Jun 2013 01:06:07 -0700

Accidentally sent this only to Martin.

Looks like James and I had the same answer.

---------- Forwarded message ----------
From: Mike Belshe <[email-masked]>
Date: Tue, Jun 18, 2013 at 5:09 PM
Subject: Re: Nit: Server-sent priority
To: Martin Thomson <[email-masked]>

> which might be different to the priority that a client requested.

I am not sure how the client would use this information.

The intent of priority was to indicate what order you'd like the other side
to process the streams.  If its a full-duplex stream (not likely HTTP), the
server and client can each assign a different priority to the other side.

They're just independent.

> previously, or relative to the priority that the server has indicated?

Indeed confusing - more reason not to do this :-)

> and 15?  Or does it indicate a priority of 6?

10< pri <15

> priority is being applied.

I'm not sure how the client would use that information - dynamically
adjust?  This seems like a non-use case.

Mike

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Jun 2013 09:14:06 -0400

The only use case I understand, in an HTTP context, for server sent
priority is on a pushed stream. And in that case the priorities are
distinctly not independent between the client and server initiated streams
(though they all apply to the response body sender).

In that case the client has to know the priority the sender is using on the
new stream (and potentially change it) so that future streams initiated by
the client can have their priorities set in a relative weigh.

An example: the client requests index.html at priority 3, the server pushes
img1 and css1. All three resources are still transferring and the client
now wants to pull img2 and img3 at the same priority as img1 (which is
still flowing) but a lower priority than css1. What priorities does it use
in its requests? It can't get that right without knowing what priority the
server has assigned to those pushes.

Is there another use case here?

On Wed, Jun 19, 2013 at 4:06 AM, Mike Belshe <[email-masked]> wrote:

> The intent of priority was to indicate what order you'd like the other
> side to process the streams.  If its a full-duplex stream (not likely
> HTTP), the server and client can each assign a different priority to the
> other side.
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Jun 2013 09:38:19 -0700

There are usecases but they are not fascinating.

E.g. The server could reprioritize a stream which had been sending video
(or other long download) for a long time at a high priority down to a lower
priority and this might be useful to know.

The case of server push has a clear usecase and little chance of erroneous
infinite loops.
-=R
On Jun 19, 2013 6:16 AM, "Patrick McManus" <[email-masked]> wrote:

> In that case the client has to know the priority the sender is using on
> the new stream (and potentially change it) so that future streams initiated
> by the client can have their priorities set in a relative weigh.
>
> An example: the client requests index.html at priority 3, the server
> pushes img1 and css1. All three resources are still transferring and the
> client now wants to pull img2 and img3 at the same priority as img1 (which
> is still flowing) but a lower priority than css1. What priorities does it
> use in its requests? It can't get that right without knowing what priority
> the server has assigned to those pushes.
>
>> On Tue, Jun 18, 2013 at 3:42 PM, Martin Thomson <[email-masked]
>> > wrote:
>>

---

From: Mike Belshe <[email-masked]>
Date: Wed, 19 Jun 2013 10:20:35 -0700

> (though they all apply to the response body sender).

I actually don't see it this way.

The server is sending (pushing) at whatever priority it wants.  Since the
stream is half-closed to the client, there is no priority-hint necessary
from the client.

> by the client can have their priorities set in a relative weigh.

I guess.  I suspect that in most cases, the push transfer is complete
before the client can react (either via sending a reprioritize or a new
stream and getting it across to the server).

> the server has assigned to those pushes.

(note: I apologize for expanding this topic in my response - there are
several issues at play)

We're into massive speculation area here about what loads pages fastest.  I
searched high and low for prioritization schemes that were markedly better
than others.  I never found one (maybe someone on this list will!).  With
the vast variety of web pages out there, all the priority schemes ended up
averaging about the same, so long as you applied basic principles.  This is
why in the end, we just went with a simple prioritization hint and left the
rest up to the implementations.  Server push throws in a whole new monkey
wrench that we never were able to prove works all that well - you're
pushing content that the client had better not already have (so you don't
clog the channel) AND you better do it at the "right" time to not slow down
the page load.  The client's reaction time is at least a half-RTT away, so
by the time you notice you screwed up it is already too late.

My advice is to leave this part of the spec open ended to the implementors.
 Best practices will emerge as people use it.  Keeping the algorithms
simple on the client will have the best chance of consistent browser
behavior.  Imagine if one browser attempts to reprioritize push streams and
another does not?  Oh - the server side hacks will be monstrous :-)

If it were up to me, I would
   1. let the client should do some basic prioritization hints on stream
create that is known to be good
   2. do not let the client reprioritize, as it will lead to browser
variance and force the servers into browser hack mode.
   3. leave all remaining priority decisions to the server.  it will learn
over time, be able to optimize for specific cases, etc.

Mike