Subject: Re: [rtcweb] Prioritization

From: Harald Alvestrand <[email-masked]>
Date: Fri, 02 May 2014 19:23:23 +0200

On 04/30/2014 11:23 PM, Martin Thomson wrote:
> On 30 April 2014 14:09, Cullen Jennings (fluffy) <[email-masked]> wrote:
>> On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 2 May 2014 22:13:27 +0200

Hi,

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

This is the current version of the paragraph in draft-welzl-rmcat-coupled-cc-02 that relates to this matter (here, SBD means Shared Bottleneck Detection), and FGI = Flow Group Identifier - a number used to decide whether flows should be controlled together):

***

   SBD uses knowledge about the flows to determine which flows belong in
   the same Flow Group (FG), and assigns FGIs accordingly.  This
   knowledge can be derived from measurements, by considering
   correlations among measured delay and loss as an indication of a
   shared bottleneck, or it can be based on the simple assumption that
   packets sharing the same five-tuple (IP source and destination
   address, protocol, and transport layer port number pair) and having
   the same Differentiated Services Code Point (DSCP) in the IP header
   are typically treated in the same way along the path.  The latter
   method is the only one specified in this document: SBD MAY consider
   all flows that use the same five-tuple and DSCP to belong to the same
   FG.  This classification applies to certain tunnels, or RTP flows
   that are multiplexed over one transport (cf. [
transport-multiplex
]).
   In one way or another, such multiplexing will probably be recommended
   for use with rtcweb [
rtcweb-rtp-usage].
***

Any comments on this text?

Our plan is to write a separate complementary document that will describe a measurement-based SBD method. Both mechanisms are in the works and we'll submit them (or: are in the process of submitting them) to RMCAT.

Cheers,
Michael