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

[Andrew Mcgregor <[e-mail]>]

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.

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
>



-- 
Andrew McGregor | SRE | [e-mail] | [phone]