Subject: Re: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Comments

From: <[email-masked]>
Date: Wed, 1 Aug 2012 10:10:48 +0200

James,

replies summed up here to keep that readable:

Standard RFCs an EF/AF/CS and others:

The intent to better explain DiffServ deployment is also part of the
ITU-work. Also other standards bodies define QoS classes (PHB groups).
Also your IETF work tries to better explain the standards, if I
understand that right.

With the exception of IETF, noone goes for 20+x DSCPs or PHBs, no
matter which layer is in focus. Neither standards bodies nor
carriers, nor the customers I'm aware off or regulation and
noone of our product managers.

My approach is: let's look what those interested in DiffServ
deployment have in common and focus on that for new standards.
Review existing standards on QoS. As you point out, IETF
depricated IP Precedence, for example. Why not review the
AF and other IETF QoS specifications now? As an example, I'm
not aware of any AF implementation with 3 drop priorities
(there are standards in the wireless community however on
a single class with 3 drop priorities, but no implementation,
I think). Why maintain 3 drop priorities in four classes?

If your aim is to inform the community how to design
DiffServ networks, why do you ignore IP Precedence
utilisation? To me it's time to accept that DiffServ is
utilsed in IP over Ethernet or IP over MPLS and so on,
usually with layer interworking, maybe with an
interconnection in between. Standards should reflect
that.

If IETF was to go for an AF review, guidance on a migration
to a new standard should be given of course.

Regards,

Rüdiger

-----Original Message-----
From: James Polk [mailto:[email-masked]]
Sent: Monday, July 30, 2012 6:19 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Comments

At 04:33 AM 7/27/2012, [email-masked] wrote:
>Hi James,
>
>some comments on draft-polk-diffserv-stds-problem-statement-01
>
>The introduction states
>
>    DSCP
>    values are used to differentiate packet treatment within an
>    intermediate node, not across a network, as the conditions affecting
>    that marking are different within each node. This is called Per Hop
>    Behavior (PHB). A packet could have the same DSCP value from source
>    to destination, but the intended mode of operation is for the DSCP
>    value to be rewritten when the packet crosses the boundary of a
>    DiffServ administrative domain. Indeed, the packet may be fully
>    reclassified at a domain boundary. The DSCP value should stay the
>    same only if adjacent domains have agreed to use the same set of
>    DSCP values and the same, or equivalent, PHBs. Inconsistency will
>    arise if a domain does not rewrite the DSCP value when receiving a
>    packet from another domain that uses a different set of DSCPs and
>    PHBs.
>
>My take is, if DiffServ design plans rewriting DSCPs at network
>boundaries, then DSCPs shouldn't be on standards track (or if at all,
>a low number only to leave room for DSCP remarking shemes).

EF is a standards track DSCP defined in RFC 3246.
AF4X, 3X, 2X, and 1X are a series of standards track DSCPs defined in RFC 2597.
CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7 are standards track DSCPs
defined in RFC 2474.
VOICE-ADMIT is a standards track DSCP defined in RFC 5865.

If you want a low number of DSCPs to be on standards track, is the above
         - too many?
                 - and if too many, which should be deprecated?
         - not enough?
         - just the right number?

I'm just trying to figure out where you want this going?

>Now the next section of your drfat states:
>
>    At issue is a combination of the number of networks or endpoints
>    that are choosing to use DiffServ markings, and the number of
>    administrative domains (called "networks" in this document) a packet
>    traverses with different policies for how packet flows of a similar
>    type (e.g., a voice flow, or an email flow, etc.) are to be marked.
>
>I'm sorry, I'm lost here. Could you describe that more precise and
>may be add a figure? That figure doesn't need to be .txt, but I'd
>appreciate it within your presentation of the draft during IETF 84.
>
>You further continue:
>
>    The community presently has RFC 4594 [RFC4594], which is an
>    informational guideline on how networks can or should mark certain
>    packet flows with differing traffic characteristics using DiffServ.
>
>Please define "community" in a terminology section (or replace it
>with another word).

the "community" is the Internet community, and everyone here knows that.

>The community I'm aware of produced a couple
>of other informational standards on DiffServ PHBs and DSCPs. Al
>Morton's presentation on the ITU liaision may contain more
>information.
>
>Apart from that, by now many carriers implemented DiffServ.
>
>Your text continues:
>
>    o  confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of
>       which is for aggregating many 6-bit DSCP values into the 3-bit (8
>       value) field available in MPLS. This confusion arises because
>       RFC 5127 is written in general terms, and indeed aggregation
>       could be used on non-MPLS paths, but the specific restriction
>       to 3 bits is due entirely to MPLS and only applies to the
>       MPLS portion of a packet's path. A similar 3-bit field exists
>       within IEEE's 802 specifications, which causes the same
>       confusion.
>
>The statement "only applies to the MPLS portion of a packet's path"
>is wrong and does not reflect all actual deployments.
>
>Deriving MPLS TC and Ethernet P-Bits from the three most significant
>DSCP bits (so called IP Precedence) is a commodity. Carriers also
>differentiate services based on IP Precedence rather than DSCPs
>on IP level, and forward traffic based on IP Precedence only.

IP Precedence was obsoleted by RFC 2474 in the year 1999.

>To me, this is a fundamental issue for any revision of RFC4594 or 5127.
>
>You go on:
>
>    o  some believe RFC 5127 is for SPs only, and want RFC 4594 to
>       reduce the number of DSCPs within its guidelines to recommend
>       using only 3 or 4 DSCPs. This seems to stem from a manageability
>       and operational perspective.
>
>Please provide an example. I've never heard of that.

I need go back no later than the Paris SVWG meeting in which someone
within the WG suggested only a few DSCPs were necessary, and that any
update to RFC 4594 should reflect that view.

>I can't support the problem statement as is.

ok

James

>Regards,
>Ruediger

---

From: <[email-masked]>
Date: Wed, 1 Aug 2012 10:53:59 +0200

[snip] and replies marked by [RG]

>BC:
>Sure. That's exactly the sort of thing I'd expect to see in
>an inter-operator or operator-customer SLA.
>
>RG: That's what it is designed for.
>I'd like to RECOMMEND just that on standards track.
>But not more than that. Once we learned, this doesn't suffice,
>let's RECOMMEND more DSCPs, PHBs, classes and the like on
>standards track. I don't say: depricate the remaining stuff.
>(but a review may be useful).

 [James]
 how exactly does one "RECOMMEND more DSCPs, PHBs,
 Classes and the like" without first creating each
 in a standards track RFC?

 [James]
 http://www.ietf.org/internet-drafts/draft-polk-tsvwg-new-dscp-assignments-00.txt
 does this creation.

 [James]
 Now we have a chicken and the egg situation. Do
 you define the traffic characteristics for each
 new DSCP before you define the guidelines but
 after you make the DSCP standards track, or do
 you do it all at the same time, while ensuring
 the golden rule of "anything new shall do no
 harm to the Internet".

[RG] My aim is to first have a look, why existing PHBs
(and DSCPs) can't be used. One of the problems I have
is that noone I know can deal with more than around
6 deployed/requested PHBs and many people comming to
standards with an application perspective continue
to tell me that the PHBs only available in standards
documents aren't good enough. Why then isn't any of
these "not good enough" PHBs, which never saw or will
see deployment, depricated? This

 [James]
 If your company does not implement the
 understanding for what to do with each new DSCP,
 what harm is caused? I submit none, because
 you'll either remark the packets to some other
 DSCP or zero the field out.

[RG]
As pointed out several times we end up in per customer
class and codepoint mapping discussions. That's neither
speeding up negotiations nor are these customers
really happy with that. That's why I've initiated
work on an interconnection PHB/class scheme.

 [James]
 At the same time, where each new DSCP can be
 used, it can be implemented with certain
 expectations for packet treatment of such marked
 packets, geared towards application expectations.
 Or, applications are the ones that are requiring
 these new traffic characteristics by claiming the
 existing treatments are insufficient or
 differentiated from other traffic that's expected
 on the same networks.
 [snip]

[RG] Two things and I talk from practice:
During my discussions with network
engineers, not naming classes by application names
was an issue. With 4 PHBs only, the philosophy is
you never know which PHB is picked by your customer
for an application. By adding more PHBs, this
isn't simplified.

[RG] I don't get the point why new applications require
new PHBs. This sounds as if operational experience
with deployed PHBs is so bad, that there's no other
choice. Honestly, who's got operational experience
with deployed PHBs in the community and does support
that point? Operational experience (with those 3-6
PHBs you'll find most often) is limited. They produce
QoS, if correctly engineered. If they don't, the
fault usually isn't caused by the DiffServ architecture
or features.
My point here is: let these new applications try the
deployed PHBs. Once this proves unresolvable issues,
go for something new on standards track.

Regards,

Rüdiger

[James]
None of this is mandating
every operator has to become aware of each
differentiated treatment characteristic, rather
they are willing to merge several treatments
together, thus creating treatment aggregates - as defined by RFC 5127 already.

>Please keep in mind: I'm out for end to end QoS, across
>many domains. There should be codepoint and PHB definition
>reserves left for future deployments (like PCN or PHB
>groups / Ordered Aggregate under 3 bit space conditions).
>Otherwise those happy to add and create own solutions
>in their domain - they can continue as today.

What about between domains that fall into an
existing treatment aggregate? That is a
fundamental point/question here that is being missed.

James

> > From: Brian E Carpenter [mailto:[email-masked]]
> > Sent: Friday, July 27, 2012 2:27 PM
> > To: Geib, Rüdiger
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [tsvwg]
> draft-polk-diffserv-stds-problem-statement-01 - Comments
> >
> > On 27/07/2012 10:33, [email-masked] wrote:
> >> Hi James,
> >>
> > That's exactly why the standards-track DSCP values are all "RECOMMENDED"
> > as the default for a particular behaviour, and it's also why there are
> > not many of them, with most of the space available for local or
> > experimental use.
> >
> >
> > That sentence seems to me to be a completely accurate summary. At the
> > insistence of the ISPs involved when diffserv was defined, each domain
> > is allowed to do what it likes, and that can lead to combinatorial
> > complexity when a traffic aggregate crosses several domains. If the
> > discussions in RFC 2475 and RFC 3086 aren't enough to describe this,
> > there is more (with non-ASCII art) in Carpenter & Nichols, Differentiated
> > Services in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494.
> >
> >> You further continue:
> >>
> >> with another word). The community I'm aware of produced a couple
> > What do you mean? If an operators *chooses* to only use a maximum of
> > 8 traffic classes, that is fine, but it is not a restriction except
> > in MPLS and 802.
> >
> >
> >> DSCP bits (so called IP Precedence) is a commodity.
> >
> > I don't know exactly what you mean by the word "commodity" here, but
> > the three most significant DSCP bits *are not* the same as IP Precedence.
> > If people are doing blind mapping of that kind, they have quite simply
> > implemented diffserv incorrectly.
> >
> >> Carriers also
> > Again, carriers can choose to do that, which is why we included
> > the Class Selector PHBs in RFC 2474. But then it is only a partial
> > implementation of diffserv and cannot capture behaviours such as
> > EF or AF.
> > The fact that carriers don't implement RFC 2474 correctly is an issue, yes.
> >
> >> You go on:
> >>
> > Some people have always complained that 3 or 4 service classes is
> > sufficient (including me, as it happens). Fine grain QoS is overrated
> > IMHO. What I object to in the model you describe is that it relies on
> > naive precedence rather than on queuing disciplines adapted to various
> > types of traffic.
> >
> >     Brian