Subject: Sending priority from a server

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 16:07:14 -0700

https://github.com/http2/http2-spec/pull/526

As it stands, I think that this isn't a good idea.

I have no problem with the idea that a server might like to request
that a client prioritize uploads, that's congruent with what we have.

However, this patch conflates the idea of requesting priority with
indicating intent.  That effectively creates a negotiation and
negotiation in protocols is something that is to be avoided.

Priority is currently conceptually easy: you say what you want the
other person to do.  When you add the possibility for negotiation,
then you are trying to reach agreement.  That's hard.  Suddenly you
have to worry about second order effects.  You start second-guessing.
You might set a higher priority than might be ideal because you
anticipate that your peer is going to go lower.

Anyhoo, I'd be happy to entertain something that allowed a server to
prioritize uploads, but this is - I think - not a great idea.

---

From: David Krauss <[email-masked]>
Date: Sat, 12 Jul 2014 09:12:06 +0800

> prioritize uploads, but this is - I think - not a great idea.

Prioritization isn’t a choice. Everything must be assigned a priority in a prioritizing multiplexer.

Is it reasonable to require that every PUSH gets default priority? Certainly not; the application very probably has some idea of the relative urgency of the information. Is the HTTP/2 definition of priority strong enough to stop a server from applying priority anyway? Also no; even if the priority is nominally default a server can order frames however it likes.

The urge to put something clever in every special case is a destructive one. At most, second-guessing should be discouraged by a note that initialized push priority is voluntary information from the server, and usually should not be taken as a basis for negotiation. But, any program that tries to treat the other side as a slave (client or server) by constructive interpretation of the protocol is going to act pathologically anyway.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 19:42:26 -0700

> The urge to put something clever in every special case is a destructive one. At most, second-guessing should be discouraged by a note that initialized push priority is voluntary information from th…

I'm not sure what point you are trying to make here.  Can you turn
that into something actionable?  a) accept the PR, b) reject the PR,
c) make some other change ?

---

From: David Krauss <[email-masked]>
Date: Sat, 12 Jul 2014 10:56:43 +0800

> c) make some other change ?

I’m in favor of the proposal.

I think your objection is an understandable misunderstanding, so it deserves a clarification in the spec. Receiving a priority isn’t an invitation to negotiate.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 20:40:06 -0700

> I’m in favor of the proposal.

Noted.

> I think your objection is an understandable misunderstanding, so it deserves a clarification in the spec. Receiving a priority isn’t an invitation to negotiate.

I don't think that there is a misunderstanding.  Whenever you have
both "you should do X" and "I'm doing X" conflated as this does,
negotiation is a naturally emergent property.  So you get a push and
the server says that it is p3, but you want it to be p7, what happens
is a negotiation, no matter how hard you say it isn't.

---

From: David Krauss <[email-masked]>
Date: Sat, 12 Jul 2014 11:54:39 +0800

> is a negotiation, no matter how hard you say it isn't.

Right. Resultant negotiation may be an emergent property from a larger prioritization system, for example if a client is going to negotiate anyway, then knowing the original nominal priority may be useful.

However, there should never be "if ( push_frame.priority ) negotiate();".

---

From: Roberto Peon <[email-masked]>
Date: Fri, 11 Jul 2014 21:01:55 -0700

I used to think sending the priority from the server was a decent idea, but
then I though about exactly what Martin is worried about:
If the server informs the client about how it is prioritizing, and the
client disagrees, then it attempts to change it.
.. and if the server then advertises the same thing...
.. rinse repeat.

You can get into nasty situations.

It is more robust to simply have the client state the priority if it cares.
-=R

On Fri, Jul 11, 2014 at 8:54 PM, David Krauss <[email-masked]> wrote:

> Right. Resultant negotiation may be an emergent property from a larger
> prioritization system, for example if a client is going to negotiate
> anyway, then knowing the original nominal priority may be useful.
>

---

From: David Krauss <[email-masked]>
Date: Sat, 12 Jul 2014 12:07:06 +0800

On 2014–07–12, at 12:01 PM, Roberto Peon <[email-masked]> wrote:

> I used to think sending the priority from the server was a decent idea, but then I though about exactly what Martin is worried about:
> If the server informs the client about how it is prioritizing, and the client disagrees, then it attempts to change it.

How does the client know whether it cares to reprioritize if it doesn’t know the current priority?

As I mentioned, setting the initial priority of every push to default=16 is both nonviable and meaningless.

What’s left is to attempt retrospective detection based on relative stream rates, which is slow, difficult, and error-prone.

A feedback loop is easily averted by not sending more than one PRIORITY per stream (!). We’re not talking about PRIORITY frames from the server here, only a prioritization field in PUSH_PROMISE.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 12 Jul 2014 20:51:21 +1200

On 12/07/2014 4:07 p.m., David Krauss wrote:
>> I used to think sending the priority from the server was a decent
>> idea, but then I though about exactly what Martin is worried
>> about: If the server informs the client about how it is
>> prioritizing, and the client disagrees, then it attempts to change
>> it. .. and if the server then advertises the same thing... .. rinse
>> repeat.
>> 
> As I mentioned, setting the initial priority of every push to
> default=16 is both nonviable and meaningless.
> 
> What’s left is to attempt retrospective detection based on relative
> stream rates, which is slow, difficult, and error-prone.
> 
> A feedback loop is easily averted by not sending more than one
> PRIORITY per stream (!). We’re not talking about PRIORITY frames from
> the server here, only a prioritization field in PUSH_PROMISE.
> 

Lets converse then:

client: HEADERS (s=1, p=999)
  "I want this. top-priority!"

server: PUSH (s1 + s=2, p=4)
   "s=1 comes with extras. I will send in background, real SLOW"

client: PRIORITY (s=2, p=999)
  "I want those top-priority as well!"

Seems reasonable information exchange. Still no obligation on the server
to actually use the client hints.

Amos

---

From: David Krauss <[email-masked]>
Date: Sat, 12 Jul 2014 17:20:20 +0800

> to actually use the client hints.

Exactly. The server gets to default to whatever priority it likes, and the client still unconditionally gets the last word.

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 15 Jul 2014 16:44:22 +0000

Yes, that's what I'm looking for: if the client is OK with the server choice it doesn't have to do anything, otherwise, it can express its wishes to the server.

I would add that the client gets the last word only up to a point: the server can ignore all the priority information sent by the client.

Hervé.

> -----Original Message-----
> From: David Krauss [mailto:[email-masked]]
> Sent: samedi 12 juillet 2014 11:20
> To: Amos Jeffries
> Cc: [email-masked]
> Subject: Re: Sending priority from a server
> 
> 
> On 2014-07-12, at 4:51 PM, Amos Jeffries <[email-masked]> wrote:
> 
> > Lets converse then:
> >
> Exactly. The server gets to default to whatever priority it likes, and the client
> still unconditionally gets the last word.
>