Re: Some HTTP 2.0 questions

you'll also surely get starvation of lower priority streams.

If the algorithm is always send higher priority if there is any, then 
what if there's _always_ some higher priority data?  The lower priority 
stuff will never get sent.  That won't look good to the clients.

I'm still thinking about aggregators, so a connection to a back-end 
server may contain streams from multiple different clients.

Surely in practise there will need to be some processing of pending 
lower-priority streams whilst there is still higher priority traffic 
pending.  So the prioritisation would be more like a weighting than a 
strict prioritisation.


------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "Mark Watson" <watsonm@netflix.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 5/12/2013 8:36:30 a.m.
Subject: Re: Some HTTP 2.0 questions
>Correct. The server should seek to use up bandwidth in the order in 
>which you've expressed via priorities, but, if unable to do so, will 
>send chunks of lower priority stuff in order to keep the pipe full.
>
>The observation is that requiring the server to absolutely follow 
>priority order means that you may starve the outgoing pipe, or fail to 
>take advantage of something that the server knows that the client 
>doesn't (yet).
>-=R
>
>
>On Wed, Dec 4, 2013 at 11:32 AM, Mark Watson <watsonm@netflix.com> 
>wrote:
>>
>>
>>
>>On Wed, Dec 4, 2013 at 9:53 AM, William Chan (陈智昌) 
>><willchan@chromium.org> wrote:
>>>On Wed, Dec 4, 2013 at 9:37 AM, Roberto Peon <grmocg@gmail.com> 
>>>wrote:
>>>>
>>>>
>>>>
>>>>On Wed, Dec 4, 2013 at 9:29 AM, Mark Watson <watsonm@netflix.com> 
>>>>wrote:
>>>>>Thanks for all the rapid responses.
>>>>>
>>>>>- yes, it was the phrase "sender-advised" that confused me in the 
>>>>>definition of PRIORITY. It's not clear that the receiver of a 
>>>>>stream can request a change to its priority, but I understand from 
>>>>>the responses below that it's intended this is allowed
>>>>
>>>>Yup. The mechanism we have today is not very efficient and requires 
>>>>implementation datastructure gymnastics, though, thus current work.
>>>>
>>>>>- modification of the request would indeed be something new at the 
>>>>>HTTP layer. But then this is HTTP2.0 ;-) The use-case I am thinking 
>>>>>of is to modify the Range, for example if the resource is somehow 
>>>>>progressively encoded and the client decides it only needs the 
>>>>>lower layers. How would this differ from canceling the old request 
>>>>>and making a new one ? The difference is admittedly minor unless 
>>>>>the RTT is large: One could cancel the old request, wait for any 
>>>>>remaining data to arrive (one RTT) then send the new request 
>>>>>(another RTT). Or one could take a guess at where the old request 
>>>>>will finish and send both cancellation and new request at the same 
>>>>>time. But then depending on how good, or bad, your guess is you 
>>>>>either have duplicate data transfer or a gap. I accept the point 
>>>>>some real world data is necessary to motivate this use-case.
>>>>>
>>>>>I have one follow-up question: IIUC, the notion of priority is 
>>>>>'soft' - that is, the server can choose to return response data out 
>>>>>of priority order. How would you implement 'hard' priority, that 
>>>>>is, where response data must be returned in priority order, or, I 
>>>>>guess, can only be out-of-order if there is no data available to 
>>>>>send from higher-priority responses ?
>>>
>>>If you don't want to pay a speed hit due to unused bandwidth (no data 
>>>available from higher priority sources), you must allow out of order.
>>>
>>>>
>>>>I'd have the client make requests with zero stream-flow-control 
>>>>window size and open up the windows in whatever order/way I saw fit.
>>>>In most cases, this is probably a losing proposition, latency-wise, 
>>>>but it can be done.
>>>>There are certainly valid and interesting usecases for using this 
>>>>mechanism to limit the amount of resources used when doing 
>>>>prefetching, for instance.
>>>
>>>Yeah, Roberto's right here, but just to emphasize...you lose much of 
>>>the gain of using HTTP/2 in the first place if you don't allow out of 
>>>(priority) order responses. And I would argue that an interoperable 
>>>HTTP/2 implementation should NOT do this. Because the performance 
>>>loss here is so substantial, that were this to become more 
>>>commonplace, this would incentivize clients to switch back to 
>>>multiple connections to get parallel downloads.
>>>
>>>PS: You may also get suboptimal prioritization the more you eagerly 
>>>_push_ into lower level queues rather than lazily _pull_ from higher 
>>>level queues. For example, once you push into the kernel socket 
>>>buffer, the application can't reorder HTTP/2 frames in that buffer, 
>>>even though there may be time left to do so before the bytes get 
>>>emitted on the wire. There are some computational tradeoffs due to 
>>>more context switches, but the later you delay the actual commit of 
>>>an HTTP/2 frame to the network, the better prioritization you get.
>>
>>​My use-case is for streaming video, where the request corresponds to 
>>chunks of video that are sequential in time. I never want later video 
>>data to be sent if there was earlier video data available that could 
>>have been sent instead, so I want the priority to be strictly 
>>respected by the server in that sense. Am I right that the spec 
>>currently would allow but not require a server to behave that way ?
>>
>>...Mark
>>
>>  ​
>>
>>
>>
>>>
>>>>
>>>>-=R
>>>>
>>>>
>>>>>
>>>>>...Mark
>>>>>
>>>>>
>>>>>
>>>>>On Wed, Dec 4, 2013 at 9:05 AM, Roberto Peon <grmocg@gmail.com> 
>>>>>wrote:
>>>>>>Look for the thread entitled:
>>>>>>
>>>>>>Restarting the discussion on HTTP/2 stream priorities
>>>>>>
>>>>>>(started on Oct 28)
>>>>>>
>>>>>>for further details about how we'd like to see priority changed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Wed, Dec 4, 2013 at 8:49 AM, Roberto Peon <grmocg@gmail.com> 
>>>>>>wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>On Wed, Dec 4, 2013 at 8:31 AM, Mark Watson <watsonm@netflix.com> 
>>>>>>>wrote:
>>>>>>>>Hi everyone,
>>>>>>>>
>>>>>>>>I recently reviewed the HTTP 2.0 draft. There are three things I 
>>>>>>>>expected to see that weren't immediately obvious how to achieve. 
>>>>>>>>Apologies if there have already been long discussions on these - 
>>>>>>>>feel free to point me at the archives if that is the case.
>>>>>>>>
>>>>>>>>(1) Canceling an HTTP request (e.g. if the client decides it no 
>>>>>>>>longer needs a requested resource). This is a pain to do with 
>>>>>>>>HTTP1.x, requiring the connection to be closed, losing all 
>>>>>>>>pipelined requests and incurring a new TCP connection 
>>>>>>>>establishment delay. I assume one could close a stream in 
>>>>>>>>HTTP2.0, canceling all requests on that stream. Does this mean 
>>>>>>>>that for individual control of HTTP requests one must ensure 
>>>>>>>>each response is on its own stream ? How does the client ensure 
>>>>>>>>that ?
>>>>>>>>
>>>>>>>A stream is a single request for HTTP/2.
>>>>>>>Cancelling the stream cancels a request.
>>>>>>>
>>>>>>>>(2) Receiver modification of stream priority. The client may 
>>>>>>>>have (changing) opinions about the relative priority of 
>>>>>>>>resources. The specification allows a sender of a stream to set 
>>>>>>>>its priority, but I didn't immediately see how the receiver 
>>>>>>>>could request priority changes. [Flow control seems to be a 
>>>>>>>>slightly different thing].
>>>>>>>>
>>>>>>>
>>>>>>>This is an open issue and is being worked on.
>>>>>>>
>>>>>>>>(3) Modification of HTTP requests. The client may wish to change 
>>>>>>>>some fields of an HTTP request. Actually the only one I can 
>>>>>>>>think of right now is Range. For example of the client decides 
>>>>>>>>it does not need the whole of the originally requested range it 
>>>>>>>>would be more efficient to modify the Range than to wait until 
>>>>>>>>the required data is received and cancel the request.
>>>>>>>>
>>>>>>>
>>>>>>>I do't think we've heard about this as a compelling usecase for 
>>>>>>>anyone yet. Why would this be significantly better than 
>>>>>>>cancelling the previous request and sending another?
>>>>>>>
>>>>>>>-=R
>>>>>>>
>>>>>>>>Thanks in advance for any pointers on these. If they are new 
>>>>>>>>features requiring more detailed use-cases I can provide those.
>>>>>>>>...Mark
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>