Subject: Some HTTP 2.0 questions

From: Mark Watson <[email-masked]>
Date: Wed, 4 Dec 2013 08:31:25 -0800

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 ?

(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].

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

Thanks in advance for any pointers on these. If they are new features
requiring more detailed use-cases I can provide those.
...Mark

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Dec 2013 08:49:42 -0800

On Wed, Dec 4, 2013 at 8:31 AM, Mark Watson <[email-masked]> wrote:

> A stream is a single request for HTTP/2.
Cancelling the stream cancels a request.

> control seems to be a slightly different thing].
This is an open issue and is being worked on.

> Range than to wait until the required data is received and cancel the
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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 4 Dec 2013 11:52:21 -0500

> own stream ? How does the client ensure that ?

you can cancel an individual transaction with a rst_stream::cancel. In
HTTP/2 parlance each transaction is on its own stream (and multiple
multiplexed streams make up the connection which subsumes the old pipeline
techniques.. each has its own stream ID).. streams are not reused as there
are plenty of integers available :).. This cancel is done all the time in
the early implementations of http/2 and spdy and the ability to do this
without terminating the connection is imo one of the under-appreciated
improvements of http/2.

> control seems to be a slightly different thing].
The priority frame is for doing what you want. I agree the wording there is
funny, but either end can advertise their desired priority for the stream.
I believe the phrasing "sender-advised" just means it is the whole stream
priority judgment of the sender of the priority frame.

> Range than to wait until the required data is received and cancel the
that's not in there and without operational experience I personally
wouldn't favor it.. but feel free to make a proposal :)

hth

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Dec 2013 08:56:51 -0800

On Wed, Dec 4, 2013 at 8:52 AM, Patrick McManus <[email-masked]>wrote:

> The priority frame is for doing what you want. I agree the wording there
> is funny, but either end can advertise their desired priority for the
> stream. I believe the phrasing "sender-advised" just means it is the whole
> stream priority judgment of the sender of the priority frame.
>

http://http2.github.io/http2-spec/#PRIORITY

> wouldn't favor it.. but feel free to make a proposal :)

Just to be clear, this is a change of HTTP semantics, right? While HTTP/2
the framing layer supports sending multiple HEADERS frames, which could
update those headers, this is not anything the web platform nor the HTTP
semantic layer currently support. HTTP/2 currently tries to avoid such
semantic changes and primarily focuses on the application transport. A
different semantic layer on top of the HTTP/2 framing layer definitely
could do this though.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Dec 2013 09:05:44 -0800

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 <[email-masked]> wrote:

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

---

From: Mark Watson <[email-masked]>
Date: Wed, 4 Dec 2013 09:29:48 -0800

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

...Mark

On Wed, Dec 4, 2013 at 9:05 AM, Roberto Peon <[email-masked]> wrote:

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

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Dec 2013 09:37:02 -0800

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

> out-of-order if there is no data available to send from higher-priority

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Dec 2013 09:53:33 -0800

>> out-of-order if there is no data available to send from higher-priority
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.
> 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.

>>>> On Wed, Dec 4, 2013 at 8:31 AM, Mark Watson <[email-masked]>wrote:
>>>>
>>>>> Hi everyone,
>>>>>

---

From: Mark Watson <[email-masked]>
Date: Wed, 4 Dec 2013 11:32:59 -0800

On Wed, Dec 4, 2013 at 9:53 AM, William Chan (陈智昌) <[email-masked]>wrote:

>>>  - 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
>> In most cases, this is probably a losing proposition, latency-wise, but
>> it can be done.

​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

 ​

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

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Dec 2013 11:36:30 -0800

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 <[email-masked]> wrote:

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Dec 2013 11:45:55 -0800

> advantage of something that the server knows that the client doesn't (yet).

Exactly what Roberto said. It's useful to additionally note that the
current integer based priority scheme makes it difficult to do this kind of
prioritization. I guess you could allocate 1 priority value per chunk. If
you're writing your own HTTP/2 client, then you have full control. If
you're trying to go through web platform bindings, then this control is not
exposed, and I doubt that it will be (but who knows). In the aforementioned
discussion link that Roberto referenced earlier, we discuss new possible
proposals to do stream dependencies instead of strict priority levels. This
would match your semantic desire perfectly, since you want to express a
reprioritizable pipeline of video chunks, which is something we had in mind
when designing the proposal. If this sort of semantic is desirable to you,
extra voices expressing this would be useful, since every time we want to
add some complexity like this, people justifiably ask "who's going to use
this?"

I'm hoping to get time this week or next week to resubmit the proposal as
an I-D as requested.

>> On Wed, Dec 4, 2013 at 9:53 AM, William Chan (陈智昌) <[email-masked]
>> > wrote:
>>
>>>> On Wed, Dec 4, 2013 at 9:29 AM, Mark Watson <[email-masked]>wrote:
>>>>
>>>>> 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
>>>>>> On Wed, Dec 4, 2013 at 8:49 AM, Roberto Peon <[email-masked]>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance for any pointers on these. If they are new
>>>>>>>> features requiring more detailed use-cases I can provide those.
>>>>>>>> ...Mark
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 04 Dec 2013 21:23:00 +0000

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" <[email-masked]>
To: "Mark Watson" <[email-masked]>
Cc: "William Chan (陈智昌)" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
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 9:53 AM, William Chan (陈智昌) 
>><[email-masked]> wrote:
>>>>>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
>>>>
>>>>>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.
>>>>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.
>>>
>>>_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.
>>
>>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
>>>>>
>>>>>
>>>>>
>>>>>>>>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.
>>>>>>>>
>>>>>>>>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 ?
>>>>>>>>
>>>>>>>>(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].
>>>>>>>>
>>>>>>>
>>>>>>>>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.
>>>>>>>>
>>>>>>>
>>>>>>>anyone yet. Why would this be significantly better than 
>>>>>>>cancelling the previous request and sending another?
>>>>>>>
>>>>>>>-=R
>>>>>>>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 4 Dec 2013 16:35:14 -0500

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 <[email-masked]> wrote:

> 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.
>
> Cc: "William Chan (陈智昌)" <[email-masked]>; "HTTP Working Group" <
> [email-masked]>
> 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.
>
>>  On Wed, Dec 4, 2013 at 9:53 AM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>
>>>>>>>> have (changing) opinions about the relative priority of resources. The

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 15:10:45 -0800

> pending.  So the prioritisation would be more like a weighting than a

Yes, that would be how I'd interpret that.  We should probably even *say*
that, so that we don't generate situations where clients are reluctant to
prioritize certain types of resources in certain ways lest they generate a
starvation situation for themselves.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Dec 2013 15:24:43 -0800

I think they should use strict prioritization. If it's long-lived
prioritization, the client is free to update the advisory priority with a
new PRIORITY frame. Moreover, in the prioritization proposal I emailed out
before and converted into an I-D, it's possible to reprioritize to assign
weighting instead of dependencies. If you truly want weighting, use a
weight.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Dec 2013 15:24:53 -0800

s/converted/am converting/

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 04 Dec 2013 23:42:40 +0000

------ Original Message ------
From: "William Chan (陈智昌)" <[email-masked]>
To: "Martin Thomson" <[email-masked]>
Cc: "Adrien de Croy" <[email-masked]>; "Roberto Peon" 
<[email-masked]>; "Mark Watson" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 5/12/2013 12:24:43 p.m.
Subject: Re: Some HTTP 2.0 questions
>prioritization, the client is free to update the advisory priority with 
>a new PRIORITY frame.
if there are multiple clients on the connection, this is just a race to 
the top priority level.  Also requires the client to try to figure out 
what the server is doing to send more commands that the server then 
needs to process amongst all the other things it is already doing.  I 
don't think this will result in a great deployment experience.

we found from our bandwidth control experience, that you still need to 
process some lower priority stuff occasionally.

Maybe this means we should ditch priority for weighting.  Or strongly 
discourage priority (if it is to be strict) in favour of weighting?

>Moreover, in the prioritization proposal I emailed out before and 
>converted into an I-D, it's possible to reprioritize to assign 
>On Wed, Dec 4, 2013 at 3:10 PM, Martin Thomson 
><[email-masked]> wrote:
>>
>>Yes, that would be how I'd interpret that.  We should probably even 
>>*say* that, so that we don't generate situations where clients are 
>>reluctant to prioritize certain types of resources in certain ways 
>>lest they generate a starvation situation for themselves.
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Dec 2013 15:44:34 -0800

With our proposal (which Will is writing up), we address the proxy problem
directly.
It was one of the motivations for the proposal in the first place :)

-=R

On Wed, Dec 4, 2013 at 3:42 PM, Adrien de Croy <[email-masked]> wrote:

> Cc: "Adrien de Croy" <[email-masked]>; "Roberto Peon" <[email-masked]>;
> "Mark Watson" <[email-masked]>; "HTTP Working Group" <
> [email-masked]>
> new PRIORITY frame.
> the top priority level.  Also requires the client to try to figure out what
> the server is doing to send more commands that the server then needs to
> process amongst all the other things it is already doing.  I don't think
> this will result in a great deployment experience.
>
> converted into an I-D, it's possible to reprioritize to assign weighting
> instead of dependencies. If you truly want weighting, use a weight.
>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Dec 2013 16:29:23 -0800

+1

Just to be clear, you've identified a problem with a single priority
context, since it makes every priority value global. But you could group
streams into a priority context/group, in which case you have relative
prioritization within groups. And amongst different groups, you should
probably use weighting.

On Wed, Dec 4, 2013 at 3:44 PM, Roberto Peon <[email-masked]> wrote:

>>> reluctant to prioritize certain types of resources in certain ways lest
>>> they generate a starvation situation for themselves.
>>>
>>
>>
>

---

From: James M Snell <[email-masked]>
Date: Thu, 5 Dec 2013 09:01:53 -0800

I'm certainly not an expert on the priority issue but relative
weighting definitely seems significantly better than the currently
insanely large priority value space. Perhaps even something as simple
as a single 8-bit increment would work... e.g.

0000 0000 = default priority weight
0001 0000 = +1
0010 0000 = +2
0011 0000 = +3
 ...
1111 0000 = +15
0000 0001 = -1
 ...
0000 1111 = -15

These would be proportional weights that could be adjusted and
balanced as necessary.

I dunno, like I said, I'm not an expert in this particular area so
this particular idea may just be nonsensical. Looking forward to
seeing the proposed modification.

On Wed, Dec 4, 2013 at 4:29 PM, William Chan (陈智昌)
<[email-masked]> wrote:
>>>>> pending.  So the prioritisation would be more like a weighting than a strict
>>>>> prioritisation.
>>>>
>>>>
>>>> *say* that, so that we don't generate situations where clients are reluctant
>>>> to prioritize certain types of resources in certain ways lest they generate
>>>> a starvation situation for themselves.
>>>
>>>
>>
>

---

From: Mark Watson <[email-masked]>
Date: Mon, 9 Dec 2013 08:08:18 -0800

Actually, I quite liked the large priority value space and the strict-ish
rule that the server should always send the highest priority data available.

That would enable the use-case I described, where audio and video chunks
are given priority values equal to their presentation time (in ms, say).
That nicely copes with the case where the chunk boundaries are not aligned
between audio and video.

...Mark

On Thu, Dec 5, 2013 at 9:01 AM, James M Snell <[email-masked]> wrote:

> what
> weighting
> >>> On Wed, Dec 4, 2013 at 3:10 PM, Martin Thomson <
> [email-masked]>
> >>> wrote:
> >>>>
> >>>>
> reluctant