Re: Some HTTP 2.0 questions

adrien - you're more or less describing the problem Will has volunteered
writing a draft for..

In the end though, this will always be a SHOULD because it is totally
unenforceable.. did the sender send the most important thing it had that
was available at that moment? The receiver will never be able to tell what
was available.. and any other policy under utilizes bandwidth.



On Wed, Dec 4, 2013 at 4:23 PM, Adrien de Croy <adrien@qbik.com> wrote:

>
> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>