W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: #436: Enable weight of 0

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Wed, 2 Apr 2014 08:35:56 +0000
To: Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532D2C49C@ADELE.crf.canon.fr>
Hi Mark,

I agree that the feeling in the room was negative, however part of it was due to the fact that the proposal relied on a choice what hadn't made yet, part of it was due to the proposal itself.

We've made the choice and I tried to clarify my proposal, so I'd like to see what's the group feeling now.

Hervé.

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: mercredi 2 avril 2014 04:57
> To: RUELLAN Herve
> Cc: ietf-http-wg@w3.org
> Subject: #436: Enable weight of 0
> 
> Hi Herve,
> 
> IIRC we discussed this as part of #270 in London:
>   <https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#-
> 270-priority-leveling>
> 
> ... and the feeling in the room was that we didn't want to do this.
> 
> Does Herve's use case below change people's minds? If not, how do people
> think he should address it?
> 
> Regards,
> 
> 
> 
> On 2 Apr 2014, at 4: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.
> > This scenario is of importance for Canon, as we would like to be able to
> download in the background heavy media from a camera, while still retaining
> the ability to control it in real time. This means that we want to have ways of
> ensuring that the data used for controlling the camera (which can be somewhat
> heavy when it includes real-time preview) can take prevalence over the other
> transfer without delay.
> > 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.
> >
> > Another scenario is to temporary suspend some groups to allow a more
> urgent group to take all the bandwidth. This can be useful when opening
> several webpages at once: only the foreground one has a weight greater than
> 0, allowing it to be downloaded quickly.
> >
> > I understand that including the value of 0 for the weight somewhat increases
> implementation complexity, but I think the benefits are well worth it.
> >
> > Cheers,
> >
> > Hervé.
> >
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
Received on Wednesday, 2 April 2014 08:36:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC