Subject: [tsvwg] Update to -rfc4594-update- on DiffServ

From: James Polk <[email-masked]>
Date: Tue, 17 Jul 2012 14:28:50 -0500

as an individual

I've revised the RFC 4594 Update draft here
https://datatracker.ietf.org/doc/draft-polk-tsvwg-rfc4594-update

I inserted a new section 2.4, which discusses the differences between 
service classes and (RFC 5127 defined) treatment aggregates. I 
believe some in the WG are conflating the two topics - which are different.

Also in Section 2.4 are example configurations of how only 3 or 4 
treatment aggregates to handle many more service classes.

In fact, there are only 4 treatment aggregates defined now, 
regardless of how many service classes there are. I plan on 
presenting in the TSVWG meeting the possibility for a 5th treatment 
aggregate, one that I'm not yet convinced is necessary yet. The idea 
of a 5th treatment aggregate is not yet in the text of the draft, as 
I'd like to get some feedback before proceeding down that path.

Comments and questions are requested

James
(with my individual hat on)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jul 2012 08:14:16 +0100

On 17/07/2012 20:28, James Polk wrote:
> service classes and (RFC 5127 defined) treatment aggregates. I believe
> some in the WG are conflating the two topics - which are different.

I think this is useful, but since this is proposed to be a standards
track draft, and 5127 (like 4594) was Informational, I wonder whether
you shouldn't attempt even more of a roll-up of the two older
documents? If not, you are pretty much telling the reader to consult
5127 in order to understand the current draft, and that is a normative
reference.

Perhaps it would be enough to introduce and define the notion of
"treatment aggregate" in the Introduction. At the moment, section 2.4
is a bit of a surprise.

    Brian

> In fact, there are only 4 treatment aggregates defined now, regardless
> of how many service classes there are. I plan on presenting in the TSVWG
> meeting the possibility for a 5th treatment aggregate, one that I'm not
> yet convinced is necessary yet. The idea of a 5th treatment aggregate is
> not yet in the text of the draft, as I'd like to get some feedback
> before proceeding down that path.
>

---

From: James Polk <[email-masked]>
Date: Wed, 18 Jul 2012 19:47:58 -0500

Brian

I've always planned to do a redo of RFC 5127 based on if and where 
the WG wants to take the RFC 4594-update proposal. I figured that 
once I see the RFC 4594 proposal gain some traction, I'll start at an 
update to RFC 5127. If the initial update was deemed useless (or 
worse), I wouldn't bother with the time and energy necessary to 
update RFC 5127. I do see far less that would be updated in a RFC 
5127 proposal, but one thing is to propose it move to a standards track also.

Additionally, noticing there is no intro text mentioning the idea of 
treatment aggregates as bad is a quite valid, and an oversight on my 
part. I'll have new Intro text in the next version to make sure 
readers are aware the discussion is coming, and where.

Thanks for the comments!

James

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 11:33:30 +0200

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

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

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 can't support the problem statement as is.

Regards,

Ruediger

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jul 2012 13:27:27 +0100

> a low number only to leave room for DSCP remarking shemes).

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.

> appreciate it within your presentation of the draft during IETF 84.

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.

> is wrong and does not reflect all actual deployments.

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.
> To me, this is a fundamental issue for any revision of RFC4594 or 5127.

The fact that carriers don't implement RFC 2474 correctly is an issue, yes.

> Please provide an example. I've never heard of that.

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

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 09:56:44 +0200

Brian,

you sound fundamental to me. My take is, let's
see what has seen deployment and try to put that on
standards track. Best practice.

The IP precedence of EF is 5. The IP precedence of AF4 is
4 and so on. I didn't talk to the AF/EF authors, you were
closer to them. That is entirely by chance?

By the time we've deployed DiffServ, the equipment of the
dominating router vendor just supported IP Precedence as a
classifying mechanism for some purposes. From the discussions
that I had with colleagues from other carriers, I know that
this is a commodity DiffServ deployment. What I try here
is standardising what has seen deployment, not what I'd
like to get some time in future (but I propose to continue
allowing to use IP precedence - it is simple and
straightforward).
Not a new approach to IETF, I'm surprised by your
reaction.

In some parts of my mail - please refer to the draft text.
An interpretation that in IP networks the DSCP is the only
basis of DiffServ forwarding decisions is simply not true.
It is one option.

And finally you mix up classes and DSCPs. I'm proposing to
have 3-4 classes at interconnection points. James section
talks about 3-4 DSCPs as a standard. I've never heard
of that. My interpretation of DiffServ: classes aren't
indicated individual DSCPs with a one by one match.

My take is specify a four class interconnection scheme
with the following DSCPs (expressed by PHBs/classes
to keep it readable):

1 DSCP: EF, AF41, Best Effort
3 DCSP: AF3

In addition, rules how to handle network manangement
traffic marked by CS6 are useful. It may occur at
interconnection points eg. in a VPN case.

That's 7 DSCPs. It leaves reserves or expansion space for
more classes and/or DSCPs (and 3 bit codepoints).

Regards,

Ruediger

-----Original Message-----
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

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jul 2012 09:57:10 +0100

> closer to them. That is entirely by chance?

Not at all; this was a conscious choice for the case where
traffic marked with the default DSCPs happened to cross into
a traditional domain without being remarked.

> allowing to use IP precedence - it is simple and

Yes, but the intention was to leave operators free to do what
they said at that time they wanted.

> Not a new approach to IETF, I'm surprised by your

I'm not against documenting the current practice among certain
operators, but I see no value in putting it on the standards
track rather than leaving it to operator agreements.

> indicated individual DSCPs with a one by one match.

One confusion here is that the diffserv documents (RFC 2474, 2475
and 3260) do not define the phrase "traffic class" except as the
name of a field in the IPv6 header. The term "behavior aggregate"
is defined as all traffic carrying a specific DSCP, which does
create a 1:1 correspondence.

Certainly, AF adds the notion of a class but only in the context
of an AF PHB group.

> 1 DSCP: EF, AF41, Best Effort

How can you have AF41 on its own?

> 3 DCSP: AF3

Sure, but that is three PHBs = three traffic aggregates

> more classes and/or DSCPs (and 3 bit codepoints).

Sure. That's exactly the sort of thing I'd expect to see in
an inter-operator or operator-customer SLA.

    Brian

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 13:23:12 +0200

[snip] part explaining that IP precedence for historical
reasons is present in the DiffServ design.
Seem to agree on that.

[RG_old: Let's explicitely put that to standards.]

BC:

RG: This is done within carrier networks. If carrier A uses
AF3 and B only supports the precedence, their services
interoperate if B only sends traffic in the single desired
AF3x PHB (AF31 I'd suppose). It's important to be aware
that IP precedence is useful to aggregate traffic within
a single AF PHB group.

> indicated individual DSCPs with a one by one match.

BC:

BC:

RG: unfortunately DiffServ terminology has never been used apart
from DSCP and PHB. PHB is used quite flexible (I just had to
re-read 3260). Class to me is a "PHB group" then.
3260 also states that the AF terminology in RFC2597 is confusing
in some parts. I agree.

> 1 DSCP: EF, AF41, Best Effort

BC:

RG: As I mentioned, existing deployments. Design
constraint: one PHB for EF, delay and jitter optimised. In
addition another delay optimised PHB, but slightly more
relaxed engineering than EF (a general purpose UDP traffic PHB).
Many European carriers picked AF41. There's currently no need
for the other AF4x DSCPs. See GSMA IR.34.

> 3 DCSP: AF3

BC:

RG: It's a single AF class / PHB group. It's a single queue.
It's a single IP Precedence. A carrier can support 3 PHBs and
will not loose information if connected to a carrier
aggregating this traffic to a single class. Fully AF
compliant.

> more classes and/or DSCPs (and 3 bit codepoints).

BC:

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

Ruediger

---

From: James Polk <[email-masked]>
Date: Mon, 30 Jul 2012 11:18:34 -0500

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

>with another word).

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

>The community I'm aware of produced a couple

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

>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

---

From: James Polk <[email-masked]>
Date: Mon, 30 Jul 2012 11:29:43 -0500

Brian

We differ in opinion wrt whether or not fine grained QoS is overrated 
- at least in some networks, I agree with all your other points below.

James

---

From: James Polk <[email-masked]>
Date: Mon, 30 Jul 2012 11:37:46 -0500

>an inter-operator or operator-customer SLA.

The IETF is not limited to defining only what 
occurs within a service operator's networks 
though. One of the fundamental charges the IETF 
has is interoperability of IP technologies where 
multiple vendors are adjacent to each other. This 
adjacency is *not* limited to inter-operator or 
operator-customer SLA areas exclusively.

James

> > To: Geib, RÃ¼diger
> > Subject: Re: [tsvwg] 
> draft-polk-diffserv-stds-problem-statement-01 - Comments
> >

---

From: James Polk <[email-masked]>
Date: Mon, 30 Jul 2012 11:54:47 -0500

>(but a review may be useful).

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

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

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

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.

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

>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