Re: [quicwg/base-drafts] HTTP/3 Zero-weighting (#2723)

[Robin Marx <[e-mail]>]

Thank you all for the comments!


> Why not make zero take precedence over any weights and avoid the dumb error:
> As long as there are 0 weights the first such is served, then weighted entries. You could also call this infinity weight.

I considered this, but that would again introduce the need for a special case treatment of the default situation (e.g., the orphan placeholder). I feel that the "dumb error" is really quite dumb and should be quite rare, as you would need to specify a weight and add the node to a placeholder that also has zero-weighted streams attached to it for it to come into play. That type of error is not specific to this proposal and would always lead to weird behavior. I expect it more likely that people will just not use placeholders/weights at all, and we end up in the FCFS case.

> Sequentially sending both before and after non-zero weighted nodes could potentially be supported by hijacking weight 256 for sending sequentially after non-zero weighted nodes and using weight 0 for sending sequentially before non-zero weighted nodes.

That being said, I do really like the symmetry behind this approach. I would reverse the semantics you propose though: 255 takes precedence over everything, 0 is lowest priority. It adds a bit of extra complexity, but this might be worth it. I will try to make some example graphs for this too.

> The situation I would like to be able to cover is a page with several videos (or animated gifs) and a few async scripts. You want these videos to start playing asap and all together (before scripts load), but you do not want to wait till videos are completely downloaded to begin loading those async scripts (which should load serially).

If I understand your use case correctly, this is supported by adding 2 sibling placeholders (PH): 1 placeholder for the videos and 1 for the scripts. The video PH would for example get weight 60 and all videos are added to it with an (equal) weight so they get transferred in parallel. The script PH would get weight 30 and all scripts are added to it with weight 0 so they get transferred sequentially. The videos/scripts would then get about 2x as much bandwidth as the scripts (60 vs 30). 

This is normal HTTP/2 behaviour and supported by this proposal and #2700 and also the current HTTP/3 draft text. The main change for this proposal (and also #2700) is that you can add the scripts to the PH with weight 0 and they automatically are transferred sequentially. Without this, you would need to add a script to the previous script node (instead of the placeholder) to get the sequential behaviour. See both compared in the image below. 

 In the case of @pmeenan's proposal, iiuc, you would put scripts in concurrency 2 and videos in concurrency 1 and they would automatically share the bandwidth 50/50 (while here we can specify the weights in more detail). 

![2019-05-19 12_25_52](https://user-images.githubusercontent.com/2240689/57980888-5506b580-7a31-11e9-965d-faacc4b212ed.png)


> I do not like creating arbitrary priorities where none are warranted. Let the server pick its own priority, if it is all the same to the User Agent. For example, if there are multiple zero-weight children, the server may choose to deliver whatever object is fully available in memory rather than deliver 80% of an object with the lowest ID first and only then start sending the fully-available object.

This is a good point and of course still possible. The priorities in the HTTP/3 and HTTP/2 texts can perfectly be overridden by a server if it feels it has a better grasp on the situation. However, as I understand it, for HTTP/2 most (non-proxy) servers do not do custom logic and implement the spec and as such, the spec needs to have sensible defaults. 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2723#issuecomment-493745276