Re: Some HTTP 2.0 questions

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