RE: Enable weight of 0

> -----Original Message-----
> From: David Krauss [mailto:potswa@gmail.com]
> Sent: mardi 1 avril 2014 21:19
> To: HTTP Working Group
> Subject: Re: Enable weight of 0
> 
> 
> On 2014-04-02, at 1:10 AM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
> wrote:
> 
> > I think we should change the range of weights for a group from 1-256 to 0-
> 255.
> >
> > The meaning of the weight 0 is to indicate that no resource should be
> allocated to the priority group, unless there are available resources that can't
> be used by any priority group with a weight greater than 0.
> >
> > This new weight would help better handling several scenarios.
> >
> > First, the downloads from a website could be put in a group with a weight of
> 0: they would not impede the user's navigation inside the website, taking
> advantage of the network idle time when the user is reading a page.
> 
> Would it not be a compliant extension for the server to apply such semantics to
> a weight of 1? The precision of resource allocation is an implementation detail.

I think it would be compliant for the server (or mostly compliant), however, the client wouldn't be able to know in advance what the server behavior would be. With a weight of 0, a client could expect any server to follow its hints and provide the expected behavior.

> > This scenario could be handled by using flow control, but this result in some
> added latency: at least 1 RTT would elapse between a server finishing to send
> the data corresponding to a webpage and the server receiving the window
> update unblocking the flow control for the downloads. The same holds when
> starting to transfer a webpage content. In addition, this would create
> interdependencies between priorities and flow control.
> 
> Yes, I agree completely. It's a slow way to communicate what should be a
> timely message. Proxies and balancers need to try to tolerate what would
> otherwise be misbehavior.
> 
> Also, if semantically meaningful underflow is eliminated, the flow control
> scheme overhead may be cut in half and its complexity reduced accordingly.
>

Received on Wednesday, 2 April 2014 08:41:00 UTC