Re: Priority signals in HTTP/2

[Martin Thomson <[e-mail]>]

Thanks for the input Greg.

On Sun, Dec 20, 2020, at 02:00, Greg Wilkins wrote:
> > about the importance of having prioritization in a multiplexed transport (though not necessarily signaling thereof).
> 
> Lost me here!    I'm just not sure that it is universally true that 
> priorities are needed in a multiplexed transport.   I'm sure there are 
> some circumstances that need them, but I am far from convinced that 
> they are generally required nor that the complexity of implementation 
> is justified in many of the cases that they might be conceptually 
> useful.

I'm not talking about sending signals to the other side, I'm talking about an endpoint allocating its resources in a fashion appropriate to their needs.  When we say PRIORITY, we refer to one endpoint telling the other what it wants.  We don't need that necessarily if you know enough from context.

I think that we have enough information now to know that - in general - it is good to know what is most important to send and prioritizing sending that.

> > 4.    Point to the new signaling system if that is mature enough (and probably even if it is not).
> 
> I don't think that any new priority signalling system should be linked 
> or recommended unless it has been proven to be of general benefit.
> However, I'd not be opposed to defining a general signalling system 
> that would allow consenting endpoints to exchange arbitrary signals. 
> Such a system could be used as the basis for a priority conversation 
> if/when something is agreed, but would be ignorable by non 
> consenting/participating endpoints.  It would also better allow for 
> experimenting with alternate solutions and optimizations (eg perhaps 
> some extension to flow control would be better than priorities).

This is the part that is hard.  I don't think that we can safely point to a general benefit from any scheme yet.  Nor do I think that this reference would need to be as firm as "please use this instead".  I was thinking that it would be of the form "other methods of signaling priority might be developed, see [x]".  Sticking a recommendation on it would be premature, I agree.

It's quite possible that FIFO handling of queries will serve you fine.  Robin Marx showed that that is far better than round robin for a few use cases.

> So the careful wording should say that the RFC7540 priorities may help 
> performance in some circumstances, but that it may also be valid to 
> ignore them. Ie it should say "your mileage may vary"!

Yes.  You correctly identified one of the challenges with the 7540 scheme: in addition to the non-trivial engineering cost of doing something complicated, you have the uncertainty associated with knowing that the extra cycles you spend were worth it.  I know that we saw some evidence that it was worth it under controlled circumstances, but it's hard to know if that research scales to large-scale deployments.