On 15 July 2013 06:51, Brian E Carpenter <brian.e.carpenter@gmail.com>wrote:

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

Well, perhaps they do.  However, using the RFC 4594 names for the bit
patterns in the packets per figure 3 of that RFC, rather than the PHB
definitions, those particular bit patterns get vaguely compatible treatment
between some router behaving per RFC 4594 PHB definitions and something
running pfifo_fast.  That is my point.

Perhaps we need another description of what is going on here, that's a
separate question, but we have those five codepoints (and perhaps a few
more, I didn't do an exhaustive search) that produce sensible behaviour in
both RFC 4594 recommended behaviour and the more widely deployed pfifo_fast.

More sensible names might well be those originally from 802.11e or 802.1p,
whichever of those coined these, those being VO ('voice'), VI
('video/interactive'), BE ('best effort') and BK ('background'), in which
case we have from my earlier example:

RFC 4594 name -> 802 name (TOS bit pattern)
AF42 -> VO (100100)
AF33 -> VI (011110)
AF21 -> BK (010010)
BE -> BE (000000)
CS1 -> BE (001000) (possibly, the different code point in this case saying
'BE, and I really mean that, this is not just default')

Using this set of bit patterns, the queueing behaviour will be correct on
many, perhaps most, existing access networks AND the 802 layer queueing
will be correct as well on a subset of those.  This would be a win, in
general.  It will also cause something sensible to happen in a network
using the mapping from RFC 4594 figure 3.

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

I believe that that local definition of the binding is a catastrophic bug
in the diffserv specs, and should never have been published in that form.
 However, too late now.  There is absolutely no way to tell an application
correctly what it should do with those bits unless there is an agreed set
of default meanings for at least some of the codepoints; maybe not total
specification of the exact behaviour, that's impractical, but at least a
way of setting some expectations.

If rtcweb continues with the code point recommendations in the draft as it
stands, code written to those recommendations will be quite seriously
broken when deployed.  The predictable outcome will be 'so turn off the
marking', and yet again an opportunity to do something sensible and
pragmatic with this feature is missed.  Let's not allow that to happen
simply because of terminology.  By saying 5 out of 64 codepoints should
have reasonable default behaviours, we might actually get this deployed.


>
>    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 <brian.e.carpenter@gmail.com
> >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 | andrewmcgr@google.com | +61 4 8143 7128