Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2012 15:21:25 +0100

Hi,

>    In other words, even though a packet has the same 
>    DSCP from source to destination, it can and often does experience 
>    different treatment depending on the conditions of the nodes it 
>    traverses on its journey. 
> 
>    The DiffServ architecture allows for DSCP values within a packet to 
>    be changed, or remarked, any number of times. In other words, a 
>    packet can have its DSCP remarked at every layer-3 hop throughout 
>    the life of that packet. This practice actually occurs infrequently,
>    but it is allowed.

IMHO, this is confusing and misses part of the diffserv model.
Rather than explaining what's wrong, here is a suggested rewrite:

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

Then you aren't clear about the fact that RFC 5127 only exists
because MPLS is lame and only has 3 bits available.

>    o  confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of 
>       which is for aggregating many 6-bit DSCP values into a 3-bit (8 
>       value) field used specifically by service provider (SP) networks.

This really should be made clear:

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

Two details on this:

>    To this end, and perhaps because of it, MPLS was designed with only 
>    8 values of priority differentiation, i.e., the 3 EXP bits. 

Afaik the reason is entirely accidental: there were 3 spare bits.

>    ...LAN based IEEE has only a 3-bit priority field as well within 
>    its specifications, known as the Priority Code Point...

... and for the Nth time, diffserv is *not* a priority scheme; it would
be worth underlining this point yet again.

I think in the end that what is lacking is a clear understanding of
the first point I made - the notion of diffserv domain boundaries
where one reclassifies the packet and/or rewrites the DSCP. If people
have this clear, I think it's fairly obvious that squeezing the DSCP
down to 3 bits in an MPLS tunnel is really a side-show. Therefore,
an update to RFC 4594 is really quite orthogonal to using, or
not using, RFC 5127.

    Brian

---

From: James Polk <[email-masked]>
Date: Tue, 19 Jun 2012 13:32:29 -0500

BRian

Thank you for the review. See comments in-line below

>IMHO, this is confusing and misses part of the diffserv model.

ok

>from another domain that uses a different set of DSCPs and PHBs."

I think this is much better than what I have. Thanks!

>because MPLS is lame and only has 3 bits available.

well... I wasn't going to write down that MPLS was lame ...   ;-)

>       MPLS portion of a packet's path."

Again, this is better text that I have now, though I'll likely add a 
little something about the PCP field within IEEE's 802 - which has 
the same limitation of a 3-bit field.

>... and for the Nth time, diffserv is *not* a priority scheme;

sorry, I know that - and probably was caught up in the thought of 
writing about the PCP field within Ethernet. I'll blame my 
proofreaders for not catching this one as well  ;-)

>it would

good idea.

>an update to RFC 4594 is really quite orthogonal to using, or

On this point, I don't believe you were in the Paris TSVWG meeting, 
so you didn't hear how many (in a row) brought this point up (and 
beat me over the head with it). Therefore, I have to stand by the 
evidence that at least some folks are still "...lacking is a clear 
understanding of the first point (you) made (above)..."

I really don't see this RFC4594-update to hinge on the aggregation 
issue within RFC5127, yet that's nearly all I heard about throughout 
the presentation in Paris. Because that clear understanding remains 
elusive still, I believe this ID - and discussion in Vancouver - is 
needed to focus the discussion on gaining a greater understanding of 
this point. Then we can discuss if the RFC4594-update is going in a 
good direction, and if so, make the necessary changes to reach 
consensus for progression of that document.

I'll update this draft quickly to have the clearer text you suggested 
included to help this discussion.

Thanks again.

James

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 09:50:22 +0200

Brian,

[RG] below indicates my replies to your statements
(marked as [BC]).

Regards, Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, June 19, 2012 4:21 PM
To: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Hi,

>    the life of that packet. This practice actually occurs infrequently,

[BC] IMHO, this is confusing and misses part of the diffserv model.
Rather than explaining what's wrong, here is a suggested rewrite:

[Text proposed by BC]

[RG-start] What you say is the PHB needs to be stable end-to-end
and the DSCP can (and looking at the deployments I am aware of
often will) vary?
Then it might be a good idea to standardise a limited set of PHBs,
if those having need can agree on them. Codepoints are secondary.
That's an often heard advice in talks with other carrier
representatives. Together with Al Morton, I've started some work
in ITU along these lines (covering IP, MPLS and Ethernet QoS at
interconnection points - a liaision statement to TSVWG is under
way, but I couldn't find an entry in the IETF liaision list today).

The commercial staff of Deutsche Telekom told me, that
they are not interested in negotiating PHB compatibilty and
codepoint mapping. They ask for a standard.

We've had interconnection talks between some carriers here
in Germany and no two of them used the same codepoints
to identify all their PHBs. What they've consented on was an
"interconnection codepoint scheme". That's reasonable and reduces
operational and commercial negotiation efforts.

In Australia / New Zealand, the regulator initiated a QoS standard
on some classes and codepoints, I was told by a colleague from the
area. I'm aware of tendencies for interconnection class and
codepoint schemes on European level.

I agree with you that carriers can map codepoints. Besides creating
additional work while agreeing interconneection, it's also not the
task of the operational staff to somehow get along with a lack of
standards - be that dealing 20 something (sub)classes or codepoints
where hardly more than 6-9 are required or the mapping of DSCPs
to 3 bit MPLS/Ethernet codepoints.

Finally, I think the IETF process includes clean up and improvement
when advancing an RFC (which I'd apply also to informational RFCs
being put on standards track after years). I will support
any work which results in a clean up of RFCs 4594 and RFC 5127.
I will not support them unchanged or with even more classes
and codepoints on standards track. And yes, I think both RFCs
need to be revised together, if one is put on standards track.
[RG-end]

[BC from here on] Then you aren't clear about the fact that RFC 5127
only exists because MPLS is lame and only has 3 bits available.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2012 09:28:17 +0100

Ruediger,

Thanks for your comments.

> and the DSCP can (and looking at the deployments I am aware of

If you want consistent behaviour from end to end, that is correct,
and that was the intention from the beginning. It's also the
reason we defined PHBIDs (RFC 3140), in case the PHB needed to
be signalled in some way (e.g. in SLA signalling).

> codepoint mapping. They ask for a standard.

However, at the time we designed diffserv (I was WG co-chair for
that), we got a very strong message from the operators involved
that they *required* the flexibility to define their own PHBs.

I'm not against what amounts to an operator's agreement on a
set of recommended PHBs, and I can understand why carriers
might want that - otherwise you need a commutative string of
SLAs along the whole path. In fact, the reason we defined
PHBIDs was so that there could be an unambiguous definition
of many more PHBs than you can fit in a 6 bit space, allowing
for a locally configured mapping down to 6 (or even 3) bits.
I think it's time for people to start using RFC 3140.

> operational and commercial negotiation efforts.

Exactly. Again, that was why we invented PHBIDs.

> codepoint schemes on European level.

Er, there is no common regulator for AU and NZ. Do you have a reference
for this work?

> need to be revised together, if one is put on standards track.

I have always believed personally that only a few PHBs are needed
and that 6 bits is plenty. But as I said, the operators involved in
the diffserv design insisted on more flexibility. However, a
BCP that recommends (not mandates) a finite set of PHBs would be
consistent with both views.

I don't see any harm in defining more PHBs, if in line with RFC 3086.
They will not be mandatory. However, we shouldn't confuse details
of specific SLA parameters or specific QoS implementations with the
general idea of a PHB. (In my not in the least humble opinion, that
is the problem with RFC 3246.)

Regards
    Brian

---

From: John Wroclawski <[email-masked]>
Date: Wed, 20 Jun 2012 01:55:32 -0700

Hello,

On Jun 20, 2012, at 12:50 AM, Ruediger Geib <[email-masked]> wrote:
>  Brian,
>
>  [RG] below indicates my replies to your statements (marked as [BC]).
>
>  Regards, Rüdiger
>

However the original diffserv model specifically 
contemplated that the PHB might *not* be stable 
from end to end.

Since the per hop behavior applied to a packet is 
only one aspect of the overall QOS seen by that 
packet within an administrative domain, there are 
two reasons this might be so.

1) Different administrative domains along an end 
to end path are using different technical means - 
different combinations of PHB, border traffic 
shaping, admission control, overcapacity, etc - 
to implement the same overall QOS for a service 
class, or

2) Different administrative domains along an end 
to end path are providing different QOS to the 
data flow due to different administrative 
agreements, etc.

4594 touches on this:

  "Each domain may choose to implement different service classes or to
  use different behaviors to implement the service classes or to
  aggregate different kinds of traffic into the aggregates and still
  achieve their required characteristics.  For example, low delay,
  loss, and jitter may be realized using the EF PHB, or with an over-
  provisioned AF PHB."

Consequently I'm not sure I would actually agree with the following

On Jun 20, 2012, at 1:28 AM, Brian E Carpenter wrote:
>  and that was the intention from the beginning.

In fact I'd say rather that the intention was to 
support the notion that different administrative 
domains might explicitly choose to implement the 
same QOS for a flow or class of packets using 
different technical means, as convenient and 
appropriate for the domain, and that this should 
be supported in the architecture.

cheers
john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2012 16:14:30 +0100

On 2012-06-20 09:55, John Wroclawski wrote:
> However the original diffserv model specifically contemplated that the
> PHB might *not* be stable from end to end.

Yes, indeed - you can only assume stability if there are e2e agreements
in place; the only safe assumption is that it might change.

> Since the per hop behavior applied to a packet is only one aspect of the
> overall QOS seen by that packet within an administrative domain, there
> are two reasons this might be so.
> 
> 1) Different administrative domains along an end to end path are using
> different technical means - different combinations of PHB, border
> traffic shaping, admission control, overcapacity, etc - to implement the
> same overall QOS for a service class, or
> 
> 2) Different administrative domains along an end to end path are
> providing different QOS to the data flow due to different administrative
> agreements, etc.
> 
> 4594 touches on this:
> 
> In fact I'd say rather that the intention was to support the notion that
> different administrative domains might explicitly choose to implement
> the same QOS for a flow or class of packets using different technical
> means, as convenient and appropriate for the domain, and that this
> should be supported in the architecture.

Yes, you are correct, but a set of operators who choose to use the same
set of PHBs can achieve more consistent behaviour by doing so. However,
if a stream of packets arrives via an operator who does not make the same
choice, it needs to be reclassified and re-marked (in the simplest case,
marked as Best Effort); there's no way out of that.

Therefore, even if a BCP is published that defines a recommended set
of PHBs, you still need to classify traffic from any source that is
not definitely known to implement that BCP.

    Brian

---

From: James Polk <[email-masked]>
Date: Wed, 20 Jun 2012 16:47:49 -0500

At 02:50 AM 6/20/2012, [email-masked] wrote:

<snip>

>need to be revised together, if one is put on standards track.

<snip>

Ruediger

Just trying to be clear here, you don't want any increase in the 
number of service classes or treatment aggregates (of service 
classes)? The two are very different.

Hearing you in Paris, as well as reading what you've said on several 
email threads - including what you have above from today, I believe 
you are not approving of additional treatment aggregates. I could be 
wrong though, and therefore am asking directly.

James
(individual hat on in all these discussions)

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 08:52:45 +0200

James,

I'm not opposing new classes in general. I agree to anything new if

- there's a clear demand of many parties requiring more than what we have
- that new stuff remains experimental or informational, especially if
   suggested by individuals only

I'm favouring the use or the modification of what's available. I'd in fact
be interested to learn how man providers have implemented AF41, 42 and 43.
I'd expect to see support for AF41. The same holds for the other AF classes.

What I hear you suggesting is "let's make classes and codepoints a
standard of which we don't know or care whether anybody deployed them".
And the other message: by the way, I got more to be put on standards track.

I've been dealing with ATM interconnection and I work on the IP/MPLS/Ethernet
QoS architecture of Deutsche Telekom. In both cases, a lack of a clear and
crisp standards on how to build E2E transport services based on a technology
will at least delay deployment.

The statement "we are not interested in long technical negotiations" from
commercial folk related to IP QoS interconnection rings a bell for me.
That's exactly what they've said when we interconnected ATM. The latter
wasn't a success story.

What I'd be really happy with:

  4 QoS classes / PHBs as standard

  7-9 DSCPs, if we can agree on them as standard. The aim is here:
  universal support, mappings are a "may" at best.

  Some standard MPLS TCs

  New DSCPs / classes go experimental/informtional - if required at all.

  Review of the AF classes and of some CS classes as well.

  Putting IP-Precedence to MPLS TC/P-Bit copying into an apropriate document
  (be it a BCP or a standard) - that's about cross layer QoS interworking.

Some not assigned DSCP/MPLS TC and Ethernet P-Bit space to leave room for
migration, new services and carrier internal QoS classes (I regard
network management/routing as a (sub)class not to be shared with externals).

As mentioned, some ITU documents are under way to IETF. Apart from that,
I'm happy to submit a draft or act as a content providing co-author. But
I won't be able to do that prior to Vancouver (I also won't participate
physically and remote participation may depend on the time slot).

Regards,

Rüdiger

-----Original Message-----
From: James Polk [mailto:[email-masked]]
Sent: Wednesday, June 20, 2012 11:48 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

<snip>

<snip>

Ruediger

James

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 09:09:47 +0200

John,

you've emphasised

I'd like to understand which approach you favour:

- RFC4594 is informational and should be left like
  that to continue giving freedom while deploying
  DiffServ.

- Standardise a limited set of PHBs and assigned
  codepoints. This allows for some E2E QoS
  deployments and leaves room for other, more
  flexible deployments.

- Standardise all QoS class/codepoint assignments
  of RFC4594 and add some new ones. This limits
  space for deployment of flexible schemes.

Regards,

Rüdiger

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 09:21:21 +0200

>>>  and the DSCP can (and looking at the deployments I am aware of
BC  If you want consistent behaviour from end to end, that is correct,
>>  and that was the intention from the beginning.
JW  In fact I'd say rather that the intention was to support the notion that
> should be supported in the architecture.

[BC]

[RG]
Thank's Brian, that's exactly what the company I work for can't deal
with. Quality of Service as described above is a "maybe". It
can't be defined in commercial terms, monitored or operated or be
explained to a customer.

A BCP or any other document which is giving clearer guidance than
the AF specification or RFC4594 will help. Look at EF to see something
which sees widespread deployment. EF can be put on standards track
any time and the expectation to see E2E deployment is justified.

Regards,

Rüdiger

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2012 13:32:44 +0100

I need to highlight one remark by Rüdiger:

On 2012-06-21 08:21, [email-masked] wrote:
...
> Quality of Service as described above is a "maybe". It

That is Internet 101. I've been dealing with operators such as
your employer since the time when they were still called PTTs,
and I know that this is as hard for them to accept now as it was
in 1990. However, there will *always* be best effort traffic in
the Internet, and I suspect it will always be the majority of
traffic. As I have been known to say, you can't beat queueing
theory. At best, diffserv can partially compensate for this, but
that's all.

I understand that this may be hard to explain to business
managers, but it does set limits on what we can achieve.

    Brian

---

From: <[email-masked]>
Date: Fri, 22 Jun 2012 13:29:11 +0200

Brian,

the core network of the company I work for is as
connectionless as can be, i.e. we apply metric
optimisation based Traffic Engineering.
This is made QoS aware. We've adapted our core network
architecture, introduced Traffic Engineering and deployed
QoS from 2000 on. The resulting service is meeting commercial
service requirements (I recall my boss having a smile in
his face when he compared figures of measured IP core
delay variation with the 125 us of ISDN).

The IP/MPLS core network exposes deterministic behaviour
under foreseeable operational conditions.

This I expect to be true for all carriers applying
Traffic Engineering. But also data center providers
nowadays engineer their infrastructure on other factors
than just cost.

Part of all the engineering is based on an assumption,
that the majority of traffic will be Best Effort.

I hope, you and other senior IETF members keep in mind,
that while the age of PTTs is over, also the "Internet
of 1990" is no longer existing.

Regards,

Rüdiger

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Thursday, June 21, 2012 2:33 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2012 12:50:07 +0100

Rüdiger,

I don't think we disagree in any fundamental way. However, when
you say "we've deployed QoS from 2000 on", can you state which
technology you mean?

Regards
   Brian Carpenter

---

From: <[email-masked]>
Date: Fri, 22 Jun 2012 16:11:01 +0200

Brian,

would the he reply

DiffServ, deployed in the complete core network (IP and MPLS)

be sufficient? Up to now, we didn't deploy or operate any RSVP
based solutions.

Regards,

Rüdiger

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Friday, June 22, 2012 1:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Rüdiger,

Regards
   Brian Carpenter