Re: Some HTTP 2.0 questions

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

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.

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