Re: Some HTTP 2.0 questions

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.


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