Re: Constant priotrity (Was: SYN_REPLY)

Many will, but some should likely be re-prioritized. This is what we've
been arguing, and for various reasons, some of which are:
  don't want a video or similar stream monopolizing all bandwidth,
especially when not looking at the tab
  want to ensure that the active tab gets the most bandwidth when loading a
bunch of tabs, e.g. at startup when restoring tabs, or when opening up a
large number of tabs
  want to ensure that resources in the active viewport are given bandwidth
(a further refinement of the idea above)
  want to ensure relative fairness from a proxy, but don't want to throttle
the server unnecessarily

One of the earliest things we played around with was what you're
suggesting-- sending the first X bytes of images, and then continuing,
ostensibly so the layout engine could figure out layout more quickly,
causing fewer reflows, etc. but it didn't yield significant gains at the
time.
That was some time ago, so another experiment along those lines is
interesting.
... but, the interesting thing is that this is 100% within the bounds of
implementation leeway. If a particular implementation finds that this is a
good optimization, then I'm sure we'll see it happen. Ditto for other
similar refinements such as sending progressive images in more intelligent
ways so that the page is useful more quickly.
I don't think it is especially interesting to have the browser specify
this. Much of the time it won't know what the resource is, etc, and so the
hint is likely going to instruct the server to do something worse than what
it would do with the knowledge it has about the resources...
-=R



On Fri, Feb 22, 2013 at 1:44 AM, Yoav Nir <ynir@checkpoint.com> wrote:

>
> On Feb 22, 2013, at 2:38 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
> > Browsers are *extremely* likely to use this, and they're where we're
> most bandwidth constrained.
> > The goal is to allow the browsers to emit requests as soon as they're
> encountered.
>
> Hi Roberto
>
> should resources have the same priority throughout their transmission?
>  Some resources, such as images and maybe music/video, we'd like to get the
> start of early on.
>
> All image formats that I know of have the image dimensions at the
> beginning. So if you have a tag like <img src="…"> the browser has no idea
> how much room to leave for the image. So with some sites you get some
> initial rendering, and then the page elements begin moving all over the
> place, adjusting to the actual size of the image, even before most of the
> image is displayed. I think it should be our goal to minimize this "moving
> around" time. OTOH we don't want images to have the highest priority in
> general.
>
> Perhaps it would help to have the browser specify an "initial boost" for
> the resource, so that the first X bytes (X determined by the server) are
> sent with very high priority, afterwards dropping to their regular priority
> as specified by the client. This can't be done with a subsequent PRIORITY,
> because X should be small relative to the amount of data the server manages
> to send within a round-trip time.
>
> What do you think?
>
> Yoav
>
>