Re: Nit: Server-sent priority

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



On Tue, Jun 18, 2013 at 4:15 PM, Roberto Peon <grmocg@gmail.com> wrote:
> 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
>
>
> 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.
>>
>> 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.
>>
>

Received on Wednesday, 19 June 2013 00:36:49 UTC