Re: [rtcweb] Prioritization

On 04/30/2014 11:23 PM, Martin Thomson wrote:
> On 30 April 2014 14:09, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>> On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:
>>
>>> If a "lower priority" packet is dispatched before a "higher priority" packet in order to "prevent starvation", then what does "higher priority" mean?
>> I think the labels reflect what "might" happen on average and not for any particular packet.
> I think that Matthew was referring to the part where the browser is
> involved.  That is, the bit where, when presented with the option to
> send just one packet from buckets A through D, how does it choose from
> those buckets.
>
> The implication was that if A is more important than B, then if A
> wants to send, it gets to send.  Period.  The "prevents starvation"
> view of the world says that work is shared between A-D, with
> increasingly large proportions of the available capacity given to
> higher priority streams.  The problem with both these models is that
> they are crap in various ways.

I wouldn't use that word; it doesn't carry any information that I can
discern.

>   In one, you get cases where lower
> priority stuff never happens, even if that isn't what you wanted; in
> another, lower priority stuff can get resources, and that wasn't what
> you wanted.

So that's a better perspective: What range of things do you want to have
happen?

My thinking is that with variable-rate encoders, it is common and simple
to make do with less resources than you expected to have; it is more
complex to program for the case where transmission ceases totally for
some of the channels, some of the time.

So my argument for preferring round-robin schemes is that the case where
you don't want starvation to happen is more common than the case where
you want starvation to happen.

But reasonable people can disagree here.

>
> The DSCP markings and how they might interact with this are just an
> additional layer of uncertainty, primarily.
Hence the note about "under a common congestion controller" - if DSCP
markers are respected, having a common congestion controller covering
different DSCP classes doesn't make much sense - they don't "see" the
same network.

If they're not respected .... they could more usefully be grouped together.

>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.