Re: Nit: Server-sent priority

On Wed, Jun 19, 2013 at 6:14 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> 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).
>

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.



>
> 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.
>

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).


>
> 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.
>

(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





> Is there another use case here?
>
>
>
> On Wed, Jun 19, 2013 at 4:06 AM, Mike Belshe <mike@belshe.com> wrote:
>
>> Accidentally sent this only to Martin.
>>
>> Looks like James and I had the same answer.
>>
>> ---------- Forwarded message ----------
>> From: Mike Belshe <mike@belshe.com>
>> Date: Tue, Jun 18, 2013 at 5:09 PM
>> Subject: Re: Nit: Server-sent priority
>> To: Martin Thomson <martin.thomson@gmail.com>
>>
>>
>>
>>
>>
>> On Tue, Jun 18, 2013 at 3:42 PM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>>
>>> 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?
>>>
>>
>> Indeed confusing - more reason not to do this :-)
>>
>>
>>>
>>> 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?
>>>
>>
>> 10< pri <15
>>
>>
>>> 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.
>>>
>>
>> I'm not sure how the client would use that information - dynamically
>> adjust?  This seems like a non-use case.
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>