Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

[Brian E Carpenter <[e-mail]>]

On 15/07/2013 08:25, Andrew Mcgregor wrote:
> Nevertheless, specifying a priority order is exactly what tc_prio and
> pfifo_fast do... I agree it's wrong, but that's what a very large number of
> existing devices do right now, and ignoring that fact is likely to cause
> problems.
> 
> Yes, this is unfortunately a mess, and I can't see a way to avoid that
> completely.  The smaller set of codepoints I mention, AF42>AF33>AF21>(CS1
> or BE), is not comprehensive, but is at least consistently ordered; the
> tc_prio map unfortunately makes EF unusable because it ends up equivalent
> to BE.
> 
> To clarify a little, I'm saying that AF42, AF32, AF22 and AF12 are all the
> same so far as tc_prio is concerned, same for AF41, AF31, AF21 and AF11,
> and the same for AF[1234]3.  So to get some consistency between the
> schemes, I have chosen for example AF42, which is in the highest priority
> band for both, AF33 for the second, AF21 for the third, and CS1 for the
> fourth, although even that is not ideal because it puts AF21 in a
> less-than-best-effort class while CS1 is equivalent to best-effort on the
> linux-based devices.

In that case, the error is using the PHB names in the first place. The
behaviours you're describing are *not* the PHBs whose names you are using.
They need new names that describe them correctly.

To reiterate, the binding between a behaviour such as EF or AFxy and a particular
DSCP value is locally defined. If the behaviour is in fact simple preemptive
priority, please don't call it something else. The fact that Linux gets it
wrong doesn't mean IETF documents should be wrong too.

   Brian

> 
> There is considerable established practice within the game industry of
> using QoS codepoints that do map to tc_prio bands.  Therefore there's a
> commonly deployed base of both low-end routers and code that depend on that
> behaviour, and attempting to standardise something that is inconsistent
> with it seems like an exercise in futility.
> 
> I should point out that not every linux-based router does this, it is
> certainly possible to get 4594 behaviour, or ignore the TOS bits entirely,
> or do DPI to assign TOS, or remark, or pretty much any behaviour you might
> imagine.  However, the majority of linux-based devices use very close to
> the default configuration of the IP stack.
> 
> I believe rtcweb should be pragmatic about this, and accept that very
> fine-grained marking is not going to fly in the majority of cases on the
> edge of the internet, and take the benefits available from a restricted set
> of codepoints that are at least widely available, reasonably consistent in
> semantics, and commonly also result in correct behaviour from lower layers,
> particularly 802.1p and 802.11e MAC QoS.
> 
> Andrew
> 
> 
> On 15 July 2013 06:08, Brian E Carpenter <[e-mail]>wrote:
> 
>> On 15/07/2013 06:46, Subha Dhesikan (sdhesika) wrote:
>> ...
>>> The other challenge I see is with the relative position of the values
>> being different from what is traditionally known for DSCP where EF> AF4x
>>> AF3x>... How have you handled it so far in a non-web rtc environment?
>> I don't track rtcweb and have no intention of doing so, but what on earth
>> do you
>> mean by writing an inequality for DSCPs? DSCPs do not specify a priority
>> order; they identify (locally) a PHB, which is essentially a queuing
>> disciplime.
>> Suggesting that EF is "greater" than an AF behaviour is just wrong.
>>
>>    Brian
>>
> 
> 
>