Subject: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

From: Lars Eggert <[email-masked]>
Date: Wed, 5 Aug 2009 17:19:14 +0300

Hi,

this document is ready, except for one issue:

Section 7., paragraph 1:
 >    This document makes no direct request to IANA.  However this  
document
 >    allows for a set of Diffserv Codepoints to be assigned different  
ECN
 >    semantics within a controlled domain as described in [RFC4774].  A
 >    list of such DSCPs will be maintained by the PCN working group.

   DISCUSS: This text isn't aligned with appendix A.1. The text here  
says
   "the WG will maintain a list of DSCPs that are OK", while the
   beginning of appendix A.1 says "the WG decided to not define with
   which DSCPs PCN can be used" (but then the end of A.1 talks about
   maintaining a list again.) Which is it? If there is to be a list, you
   need to create an IANA registry, write management procedures for it
   (see RFC5226) and populate it with some initial values. (WGs are
   ephemeral, which is why the PCN WG can't be the maintainer of this
   list, IANA has to be.) If you want to leave it fully open for
   deployments, you need to remove this confusion from the text.

Lars

Nits:

Section 4., paragraph 3:
 >                   to prevent future compatability issues.

   Nit: s/compatability/compatibility/

Section 4.2., paragraph 1:
 >    that is guaranteeed to be copied down into the inner header upon

   Nit: s/guaranteeed/guaranteed/

Section 6., paragraph 1:
 >    always copy the CE codepoint from teh outer header into the inner

   Nit: s/teh/the/

Section 6., paragraph 2:
 >    header in decapsulation (unless the inner packet is not-ECT).   
If an
 >    operator it is essential that any operator wishing to allow ECN to
 >    exist end-to-end ensures there are no tunnel end-points within the
 >    PCN-domain.

   "If an operator it is essential that any operator..." - wording

Section 12., paragraph 0:
 > 12.  References

   Should be updated; see idnits report.

Appendix A., paragraph 2:
 >    a given PCN-domain is dependant on the nature of the traffic  
entering

   Nit: s/dependant/dependent/

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2009 14:27:20 +0300

Hi,

I'm waiting to hear from the authors/WG.

Lars

On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:

> <smime.p7s><ATT00001.txt>

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 14:05:53 +0100

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went on
a back-burner for a few days. 

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be done
purely unofficially by having a list of DSCPs on the IETF wiki and just
politely asking developers to consult it and add any new ones they are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since this
effectively replaces ECN as the default  behaviour for such DSCPs. So my
suggestion is:

Change the IANA section to say something along the following lines (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible Diffserv
codepoints. The decision as to whether to enable PCN for a given pool 1
codepoint must be made by the appropriate IETF Transport Area Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA to
maintain the experimental registry but I am not sure if they are able to
do that sort of thing? If so the following could be added to the IANA
section:

"During the early stages of adoption it is envisaged that PCN will be
used experimentally using pool 2 or 3 DSCPs (experimental or local use).
Whilst these DSCPs are not controlled by IANA normally, a request will
be made to maintain a list of PCN experiments along with the DSCPs these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D with
these updates...

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: [email-masked]
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
> 
> Hi,
>

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 09:55:10 +0200

Toby,

PCN should express to the IANA, whether one or more new DSCP is 
required to operate or carry out experiments on PCN.

As soon as IANA maintains a list of DSCPs for any purpose, this 
will have the status of a standard. 

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs 
per traffic class (DSCP bit 0-2, let's call them traffic class 
in this email) for PCN, that's 32 DSCPs in all.

If possible, PCN should limit the number of traffic classes, 
where to apply PCN.

I don't think PCN will be applied in traffic classes 0 and 6.

I'd expect PCN to be used within traffic classes 5 and 4, 
may be also 3 or 2.

Traffic classes 1 and 7 may be excluded too.

The above clearly expresses personal views, but informational 
RFC5127 to some extent backs these personal views.

I'm aware that PCN WG shouldn't standardise traffic class usage 
or come close to that. I however want to avoid repeating the biggest 
flaw of the AF specification, which in my eyes is to reserve 
12 DSCPs for 4 traffic classes.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 14, 2009 3:06 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Toby

> > <smime.p7s><ATT00001.txt>

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 18 Aug 2009 18:36:31 +0100

Ruediger,

The draft as it stands holds two inconsistent opinions:

i) "
the aim is for PCN to re-use existing DSCPs
"
(S.4.3.1)

ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:

i) applying PCN to existing DSCPs

ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we
should list the classes that might be appropriate to associate with PCN
marking.

In other words, we should only say that an operator _applies_ PCN marking
to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that
would waste DSCPs just to get a different marking behaviour for packets
requiring the same scheduling behaviour as a pre-existing DSCP. The
non-wasteful way to do this is to use one DSCP for a certain scheduling
behaviour, but set the ECN field to a non-zero value to turn on PCN
marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then
RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an example:

hi stat mux subnet

___________________

|
same   |

|           marking
|

|   _____  ____:___ |

|  |
||        ||

-------DSCPA--Not-ECT----------DSCPA--NM-------------DSCPA--Not-ECT-----------

|  |
||        ||

-------DSCPB--Not-ECT----------DSCPB--NM-------------DSCPB--Not-ECT-----------

|  |     ||________||

|  |
|          |

-------DSCPC--Not-ECT----------DSCPC--Not-PCN--------DSCPC--Not-ECT-----------

|  |_____|
|

|
_____           |

|  |
|          |

-------DSCPD--ECT--------------DSCPD--ECT------------DSCPD--ECT---------------

|  |
|          |

-------DSCPE--Not-ECT----------DSCPE--Not-PCN--------DSCPE--Not-ECT-----------

|  |_____|
|

|
:
|

|
same
|

| scheduling        |

|
(BA)
|

|___________________|

- The text on each flow shows the DSCP-ECN combination used for that
segment

- The boxes around DSCPA/B/C and around DSCPD/E represent the same
scheduling behaviour applied to multiple DSCPs in the aggregated region
(a behaviour aggregate).

- The box around NM for the first two flows represents the same marking
behaviour (PCN) applied to multiple DSCPs.

- The flows keep the same DSCP* along their whole path, so when they pop
out into the lo-stat-mux region on the other side, the DSCP is
preserved.

- In practice, traffic might be tunnelled across the hi-stat mux region,
and at the same time common scheduling behaviours might be mapped to a
single DSCP in the outer headers. The diagram merely shows everything can
be done without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually stay
the same along the whole path. It might be mapped to local DSCPs that are
each used for the same class at different points along the path.

Here's a copy of the 2nd half of Appx A.1, that I think needs to be
removed (sorry, I know I'm a co-author, but...):
"  The choice of which DSCP is most suitable for
a given PCN-domain is dependant on the nature of the traffic
entering
that domain and the link rates of all the links making up
that
domain.  In PCN-domains with uniformly high link rates,
the
appropriate DSCPs would currently be those for the Real Time
Traffic
Class
[RFC5127].  If the
PCN domain includes lower speed links it
would also be appropriate to use the DSCPs of the other
traffic
classes that
[
Voice-Admit] defines for use with admission control,
such as the three video classes CS4, CS3 and AF4 and the
Admitted
Telephony Class.  The PCN working group will maintain a
list of PCN-
compatible Diffserv Codepoints.

"

At 08:55 18/08/2009, [email-masked] wrote:

Toby,

where to apply PCN.

may be also 3 or 2.

Regards,

Ruediger

-----Original Message-----

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of [email-masked]

Subject: Re: [PCN] AD review:
draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went
on

during any early experimental adoption of PCN however that could be
done

purely unofficially by having a list of DSCPs on the IETF wiki and
just

politely asking developers to consult it and add any new ones they
are

register certain standards (pool 1) DSCPs as PCN-compatible since
this

effectively replaces ECN as the default  behaviour for such DSCPs.
So my

suggestion is:

Change the IANA section to say something along the following lines
(I

"IANA will be asked to set up a registry of PCN-compatible
Diffserv

codepoints. The decision as to whether to enable PCN for a given pool
1

codepoint must be made by the appropriate IETF Transport Area
Working

registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN
to

Change the last sentence of A.1 to "IANA will maintain a list
of

Would this cover things appropriately? I did wonder about asking IANA
to

maintain the experimental registry but I am not sure if they are able
to

do that sort of thing? If so the following could be added to the
IANA

section:

"During the early stages of adoption it is envisaged that PCN will
be

used experimentally using pool 2 or 3 DSCPs (experimental or local
use).

Whilst these DSCPs are not controlled by IANA normally, a request
will

be made to maintain a list of PCN experiments along with the DSCPs
these

experiments are using."

Once I get the nod from WG I will release a new version of the I-D
with

these updates...

Toby

> From: [email-masked]
[
mailto:[email-masked]] On Behalf Of

> >>   semantics within a controlled domain as
described in [RFC4774].

A

> >   maintaining a list again.) Which is it? If there is
to be a list,

> > you

> >   need to create an IANA registry, write management
procedures for

it

> >>   operator it is essential that any operator
wishing to allow ECN

to

> >>   exist end-to-end ensures there are no tunnel
end-points within

the

PCN mailing list

[email-masked]

PCN mailing list

[email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 08:27:28 +0200

Hi Bob,
 
I agree to your suggestion to "scrub (ii) and only have (i)..[and that] we should list classes that might be appropriate to associate with PCN marking."
 
Regards,
 
Ruediger

  _____  

From: Bob Briscoe [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

" (S.4.3.1)

I believe we should scrub (ii) and only have (i). In place of ii) we should list the classes that might be appropriate to associate with PCN marking.

In other words, we should only say that an operator _applies_ PCN marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that would waste DSCPs just to get a different marking behaviour for packets requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way to do this is to use one DSCP for a certain scheduling behaviour, but set the ECN field to a non-zero value to turn on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

                            hi stat mux subnet
                            ___________________
                           |            same   |
                           |           marking |
                           |   _____  ____:___ |
                           |  |     ||        ||
                           |  |     ||        ||
                           |  |     |          |
                           |  |_____|          |
                           |   _____           |
                           |  |     |          |
                           |  |     |          |
                           |  |_____|          |
                           |     :             |
                           |   same            |
                           | scheduling        |
                           |   (BA)            |
                           |___________________|

- The text on each flow shows the DSCP-ECN combination used for that segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same scheduling behaviour applied to multiple DSCPs in the aggregated region (a behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop out into the lo-stat-mux region on the other side, the DSCP is preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, and at the same time common scheduling behaviours might be mapped to a single DSCP in the outer headers. The diagram merely shows everything can be done without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually stay the same along the whole path. It might be mapped to local DSCPs that are each used for the same class at different points along the path.

entering

that

the

Traffic

   Class

[RFC5127 <http://tools.ietf.org/html/rfc5127> ].  If the

traffic

   classes that

[ <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-Voice-Admit> 

Admitted

list of PCN-

Toby,

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [  <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 14, 2009 3:06 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Toby

> From: [email-masked] [  <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
> Lars Eggert

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Aug 2009 09:29:26 +0100

Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in
the thread below with narrower ASCII-art to better survive word
wrap]

Cheers

Bob

At 07:27 19/08/2009, [email-masked] wrote:

Hi Bob,

I agree to your
suggestion to "scrub (ii) and only have (i)..[and that] we should
list classes that might be appropriate to associate with PCN
marking."

Regards,

Ruediger

From: Bob Briscoe
[
mailto:[email-masked]]

Cc: [email-masked]

Ruediger,

i) "

" (S.4.3.1)

To be absolutely sure it's clear what I mean, here's an
example:

hi stat mux subnet

___________________

|
same   |

|           marking
|

|   _____  ____:___ |

|  |
||        ||

--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--

|  |
||        ||

--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--

|  |     ||________||

|  |
|          |

--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--

|  |_____|
|

|
_____           |

|  |
|          |

--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------

|  |
|          |

--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--

|  |_____|
|

|
:
|

|
same
|

| scheduling        |

|
(BA)
|

|___________________|

- The text on each flow shows
the DSCP-ECN combination used for that segment

Here's a copy of the 2nd half of Appx A.1, that I think needs to be
removed (sorry, I know I'm a co-author, but...):
"  The choice of which DSCP is most suitable for
a given PCN-domain is dependant on the nature of the
traffic
entering
that domain and the link rates of all the links making up
that
domain.  In PCN-domains with uniformly high link
rates,
the
appropriate DSCPs would currently be those for the Real
Time
Traffic
Class
[RFC5127].  If the
PCN domain includes lower speed links it
would also be appropriate to use the DSCPs of the other
traffic
classes that
[
Voice-Admit] defines for use with admission control,
such as the three video classes CS4, CS3 and AF4 and the
Admitted
Telephony Class.  The PCN working group will maintain
a
list of PCN-
compatible Diffserv Codepoints.

"

At 08:55 18/08/2009, [email-masked]
wrote:
Toby,

where to apply PCN.

may be also 3 or 2.

Regards,

Ruediger

-----Original Message-----

From: [email-masked] [

Hi Lars,

suggestion is:

registry."

section:

experiments are using."

these updates...

Toby

> From: [email-masked] [

described in [RFC4774].

A

to be a list,

procedures for

it

wishing to allow ECN

to

end-points within

the

PCN mailing list

[email-masked]

PCN mailing list

[email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 09:39:55 +0100

That ASCII art is still unreadable because (for me at least) it is getting displayed in a variable-width font (Times New Roman to be exact). I ended up having to convert it to Courier to be able to see what you meant...

I am in the process of drafting a reply setting out the background to this confusion and hopefully solving it. In the meantime there seems to be a consensus that the way ahead is to recommend PCN as suitable for 1 or more EXISTING DSCPs (which means we need to decide which ones...). But that still leaves the question of whether we need to say something about what needs to happen in the future if someone (say Fred Baker) wants to add PCN to a new DSCP.

Toby

From: Briscoe,RJ,Bob,XVR9 BRISCORJ R 
Sent: 19 August 2009 09:29
To: [email-masked]; Moncaster,T,Toby,DER3 R
Cc: [email-masked]
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in the thread below with narrower ASCII-art to better survive word wrap]

Cheers

Bob

Hi Bob,

Regards,
 
Ruediger

________________________________

From: Bob Briscoe [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

" (S.4.3.1)

                   hi stat mux subnet
                   ___________________
                  |            same   |
                  |           marking |
                  |   _____  ____:___ |
                  |  |     ||        ||

Voice-Admit <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-Voice-Admit> ] defines for use with admission control,

"

Toby,

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [ mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 14, 2009 3:06 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Toby

> From: [email-masked] [ mailto:[email-masked]] On Behalf Of
> Lars Eggert

---

From: Michael Menth <[email-masked]>
Date: Wed, 19 Aug 2009 10:51:48 +0200

Hi,

I'm not sure whether the ASCII art is needed at all and I did not really 
understand it. The following message arrived with me:

PCN is locally applied to some specific DSCPs with the same scheduling 
behavior (I don't think that we can allow different one, this requires 
more study). If PCN marking applies to them, the ECN field of 
corresponding packets is set to an appropriate value by the ingress 
node, else it is set to 00. After leaving the domain, the PCN egress 
node clears the ECN field with 00. This way, no new DSCPs are needed for 
PCN.

Or have I missed a critical point?

Regards,

Michael

[email-masked] schrieb:
>
> That ASCII art is still unreadable because (for me at least) it is 
> getting displayed in a variable-width font (Times New Roman to be 
> exact). I ended up having to convert it to Courier to be able to see 
> what you meant…
>
> I am in the process of drafting a reply setting out the background to 
> this confusion and hopefully solving it. In the meantime there seems 
> to be a consensus that the way ahead is to recommend PCN as suitable 
> for 1 or more EXISTING DSCPs (which means we need to decide which 
> ones…). But that still leaves the question of whether we need to say 
> something about what needs to happen in the future if someone (say 
> Fred Baker) wants to add PCN to a new DSCP.
>
> Toby
>
> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R
> *Sent:* 19 August 2009 09:29
> *To:* [email-masked]; Moncaster,T,Toby,DER3 R
> *Cc:* [email-masked]
> *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Ruediger,
>
> Great.
>
> [As some people couldn't read it, I've also replaced the diag quoted 
> in the thread below with narrower ASCII-art to better survive word wrap]
>
> Cheers
>
>
> Bob
>
> I agree to your suggestion to "scrub (ii) and only have (i)..[and 
> that] we should list classes that might be appropriate to associate 
> with PCN marking."
>
> Regards,
>
> Ruediger
>
> ------------------------------------------------------------------------
>
> *From:* Bob Briscoe [ mailto:[email-masked]]
> *Sent:* Tuesday, August 18, 2009 7:37 PM
> *To:* Geib, Rüdiger; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Ruediger,
>
> should list the classes that might be appropriate to associate with 
> PCN marking.
>
> No-one needs any additional DSCPs to enable PCN marking. Otherwise 
> that would waste DSCPs just to get a different marking behaviour for 
> packets requiring the same scheduling behaviour as a pre-existing 
> DSCP. The non-wasteful way to do this is to use one DSCP for a certain 
> scheduling behaviour, but set the ECN field to a non-zero value to 
> turn on PCN marking (S.4.3.1).
>
> [In MPLS, as there is no ECN field, the efficient way is different. 
> Then RFC5129 describes how you would do it.]
>
> scheduling behaviour applied to multiple DSCPs in the aggregated 
> region (a behaviour aggregate).
> - The box around NM for the first two flows represents the same 
> marking behaviour (PCN) applied to multiple DSCPs.
> - The flows keep the same DSCP* along their whole path, so when they 
> pop out into the lo-stat-mux region on the other side, the DSCP is 
> preserved.
> - In practice, traffic might be tunnelled across the hi-stat mux 
> region, and at the same time common scheduling behaviours might be 
> mapped to a single DSCP in the outer headers. The diagram merely shows 
> everything can be done without tunnelling or layering.
>
> * Note: For some non-standardised DSCPs, the DSCP might not actually 
> stay the same along the whole path. It might be mapped to local DSCPs 
> that are each used for the same class at different points along the path.
>
>
> [RFC5127 <http://tools.ietf.org/html/rfc5127>].  If the
> Voice-Admit <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-Voice-Admit>] defines for use with admission control,
> [email-masked]
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 10:19:06 +0100

Certainly that is correct for baseline. In other words all we are doing is proposing PCN as an alternative marking behaviour that doesn't affect any other aspect of DiffServ directly...

That still leaves the question of which DSCPs will we initially recommend might benefit from it (Lars is keen we should mention at least one so PCN can get deployed)

Toby

> From: Michael Menth [mailto:[email-masked]]
> Sent: 19 August 2009 09:52
> To: Moncaster,T,Toby,DER3 R
> Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked];
> [email-masked]
> > what you meant...
> > ones...). But that still leaves the question of whether we need to say
> > Voice-Admit <http://tools.ietf.org/html/draft-ietf-pcn-baseline-
> encoding-04#ref-Voice-Admit>] defines for use with admission control,

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 10:30:33 +0100

Hi All,

I think there is now a possible solution to progress this. The confusion
all stemmed from the WG's desire to have a record kept of PCN
experiments which then led to the source of the confusion in the
baseline document's Appendix A.

My proposed solution (based on the comments over the past 3 days) aims
to do two things, firstly to clarify that PCN is an alternative marking
behaviour that Operators can specify for certain DSCPs (without changing
the scheduling or other behaviours), secondly it should recommend 1 (or
more) DSCPs that are currently suitable and should list what we believe
are the criteria for suitability AND/OR explain what we would expect
needed to happen if people wanted to suggest other DSCPs that it could
apply to (either existing or new ones). This second bit is more thorny
and I am not sure I am best placed to do it. I would welcome any offers
of text for that bit...

The end result will be that we have a doc that really makes no IANA
requests, that suggests a suitable DSCP to apply PCN to initially and
that explains what makes that DSCP suitable...

Toby

> Sent: 14 August 2009 14:06
just
1
with
> > >   maintaining a list again.) Which is it? If there is to be a
list,

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Aug 2009 10:30:53 +0100

Michael,

Correct.

(Except, there is a wrinkle about clearing the 
ECN field at the egress; only if e2e ECN is not being used.)

The ASCII art was merely intended to explain why 
we can't assume there will be just one DSCP for 
PCN traffic. The lo-stat-mux part of a network 
treats multiple DSCPs with multiple PHBs. But 
even if they all get treated with the same PHB 
within a hi-stat-mux core, they don't all 
necessarily get mapped to one DSCP (so that they 
can be separated out again on the other side).

Bob

At 09:51 19/08/2009, Michael Menth wrote:
>Hi,
>
>I'm not sure whether the ASCII art is needed at 
>all and I did not really understand it. The following message arrived with me:
>
>PCN is locally applied to some specific DSCPs 
>with the same scheduling behavior (I don't think 
>that we can allow different one, this requires 
>more study). If PCN marking applies to them, the 
>ECN field of corresponding packets is set to an 
>appropriate value by the ingress node, else it 
>is set to 00. After leaving the domain, the PCN 
>egress node clears the ECN field with 00. This 
>way, no new DSCPs are needed for PCN.
>
>>That ASCII art is still unreadable because (for 
>>me at least) it is getting displayed in a 
>>variable-width font (Times New Roman to be 
>>exact). I ended up having to convert it to 
>>Courier to be able to see what you meant…
>>
>>I am in the process of drafting a reply setting 
>>out the background to this confusion and 
>>hopefully solving it. In the meantime there 
>>seems to be a consensus that the way ahead is 
>>to recommend PCN as suitable for 1 or more 
>>EXISTING DSCPs (which means we need to decide 
>>which ones…). But that still leaves the 
>>question of whether we need to say something 
>>about what needs to happen in the future if 
>>someone (say Fred Baker) wants to add PCN to a new DSCP.
>>
>>Toby
>>
>>[As some people couldn't read it, I've also 
>>replaced the diag quoted in the thread below 
>>with narrower ASCII-art to better survive word wrap]
>>
>>Cheers
>>
>>
>>Bob
>>
>>I agree to your suggestion to "scrub (ii) and 
>>only have (i)..[and that] we should list 
>>classes that might be appropriate to associate with PCN marking."
>>
>>Regards,
>>
>>Ruediger
>>
>>I believe we should scrub (ii) and only have 
>>(i). In place of ii) we should list the classes 
>>that might be appropriate to associate with PCN marking.
>>
>>In other words, we should only say that an 
>>operator _applies_ PCN marking to certain existing DSCPs.
>>
>>No-one needs any additional DSCPs to enable PCN 
>>marking. Otherwise that would waste DSCPs just 
>>to get a different marking behaviour for 
>>packets requiring the same scheduling behaviour 
>>as a pre-existing DSCP. The non-wasteful way to 
>>do this is to use one DSCP for a certain 
>>scheduling behaviour, but set the ECN field to 
>>a non-zero value to turn on PCN marking (S.4.3.1).
>>
>>[In MPLS, as there is no ECN field, the 
>>efficient way is different. Then RFC5129 describes how you would do it.]
>>
>>- The boxes around DSCPA/B/C and around DSCPD/E 
>>represent the same scheduling behaviour applied 
>>to multiple DSCPs in the aggregated region (a behaviour aggregate).
>>- The box around NM for the first two flows 
>>represents the same marking behaviour (PCN) applied to multiple DSCPs.
>>- The flows keep the same DSCP* along their 
>>whole path, so when they pop out into the 
>>lo-stat-mux region on the other side, the DSCP is preserved.
>>- In practice, traffic might be tunnelled 
>>across the hi-stat mux region, and at the same 
>>time common scheduling behaviours might be 
>>mapped to a single DSCP in the outer headers. 
>>The diagram merely shows everything can be done without tunnelling or layering.
>>
>>* Note: For some non-standardised DSCPs, the 
>>DSCP might not actually stay the same along the 
>>whole path. It might be mapped to local DSCPs 
>><http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-Voice-Admit>
>>Voice-Admit 
>><http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-Voice-Admit>] 
>>defines for use with admission control,

---

From: Michael Menth <[email-masked]>
Date: Wed, 19 Aug 2009 11:33:43 +0200

Hi Bob,

Bob Briscoe schrieb:
> Michael,
>
> Correct.
>
> (Except, there is a wrinkle about clearing the ECN field at the 
> egress; only if e2e ECN is not being used.)
>
> The ASCII art was merely intended to explain why we can't assume there 
> will be just one DSCP for PCN traffic. The lo-stat-mux part of a 
> network treats multiple DSCPs with multiple PHBs. But even if they all 
> get treated with the same PHB within a hi-stat-mux core, they don't 
> all necessarily get mapped to one DSCP (so that they can be separated 
> out again on the other side).
I understand. That makes any marking behavior using two DSCPs even more 
problematic, right?

Regards,

Michael

>> I'm not sure whether the ASCII art is needed at all and I did not 
>> really understand it. The following message arrived with me:
>>
>> PCN is locally applied to some specific DSCPs with the same 
>> scheduling behavior (I don't think that we can allow different one, 
>> this requires more study). If PCN marking applies to them, the ECN 
>> field of corresponding packets is set to an appropriate value by the 
>> ingress node, else it is set to 00. After leaving the domain, the PCN 
>> egress node clears the ECN field with 00. This way, no new DSCPs are 
>> needed for PCN.
>>
>>> I am in the process of drafting a reply setting out the background 
>>> to this confusion and hopefully solving it. In the meantime there 
>>> seems to be a consensus that the way ahead is to recommend PCN as 
>>> suitable for 1 or more EXISTING DSCPs (which means we need to decide 
>>> which ones…). But that still leaves the question of whether we need 
>>> to say something about what needs to happen in the future if someone 
>>> (say Fred Baker) wants to add PCN to a new DSCP.
>>>
>>> Toby
>>>
>>> DSCP. The non-wasteful way to do this is to use one DSCP for a 
>>> certain scheduling behaviour, but set the ECN field to a non-zero 
>>> value to turn on PCN marking (S.4.3.1).
>>>
>>> mapped to a single DSCP in the outer headers. The diagram merely 
>>> shows everything can be done without tunnelling or layering.
>>>
>>> stay the same along the whole path. It might be mapped to local 
>>> DSCPs that are each used for the same class at different points 
>>> along the path.
>>>
>>>

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 10:45:12 +0100

Yes, I think any of the extended pcn encodings that uses 2 dscps needs to say something about the scheduling behaviour of the 2 dscps. The obvious thing is that they both map to the same scheduling PHB (actually, first guess is that this is the only thing that makes sense)

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Michael Menth
{ Sent: 19 August 2009 10:34
{ To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ Cc: [email-masked]
{ Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
{ 
{ Hi Bob,
{ 
{ Bob Briscoe schrieb:
{ > Michael,
{ >
{ > Correct.
{ >
{ > (Except, there is a wrinkle about clearing the ECN field at the
{ > egress; only if e2e ECN is not being used.)
{ >
{ > The ASCII art was merely intended to explain why we can't assume there
{ > will be just one DSCP for PCN traffic. The lo-stat-mux part of a
{ > network treats multiple DSCPs with multiple PHBs. But even if they all
{ > get treated with the same PHB within a hi-stat-mux core, they don't
{ > all necessarily get mapped to one DSCP (so that they can be separated
{ > out again on the other side).
{ I understand. That makes any marking behavior using two DSCPs even more
{ problematic, right?
{ 
{ Regards,
{ 
{ Michael
{ 
{ 
{ >
{ >
{ >
{ > Bob
{ >
{ > At 09:51 19/08/2009, Michael Menth wrote:
{ >> Hi,
{ >>
{ >> I'm not sure whether the ASCII art is needed at all and I did not
{ >> really understand it. The following message arrived with me:
{ >>
{ >> PCN is locally applied to some specific DSCPs with the same
{ >> scheduling behavior (I don't think that we can allow different one,
{ >> this requires more study). If PCN marking applies to them, the ECN
{ >> field of corresponding packets is set to an appropriate value by the
{ >> ingress node, else it is set to 00. After leaving the domain, the PCN
{ >> egress node clears the ECN field with 00. This way, no new DSCPs are
{ >> needed for PCN.
{ >>
{ >> Or have I missed a critical point?
{ >>
{ >> Regards,
{ >>
{ >> Michael
{ >>
{ >>
{ >>
{ >> [email-masked] schrieb:
{ >>>
{ >>> That ASCII art is still unreadable because (for me at least) it is
{ >>> getting displayed in a variable-width font (Times New Roman to be
{ >>> exact). I ended up having to convert it to Courier to be able to see
{ >>> what you meant...
{ >>>
{ >>> I am in the process of drafting a reply setting out the background
{ >>> to this confusion and hopefully solving it. In the meantime there
{ >>> seems to be a consensus that the way ahead is to recommend PCN as
{ >>> suitable for 1 or more EXISTING DSCPs (which means we need to decide
{ >>> which ones...). But that still leaves the question of whether we need
{ >>> to say something about what needs to happen in the future if someone
{ >>> (say Fred Baker) wants to add PCN to a new DSCP.
{ >>>
{ >>> Toby
{ >>>
{ >>> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ >>> *Sent:* 19 August 2009 09:29
{ >>> *To:* [email-masked]; Moncaster,T,Toby,DER3 R
{ >>> *Cc:* [email-masked]
{ >>> *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
{ >>>
{ >>> Ruediger,
{ >>>
{ >>> Great.
{ >>>
{ >>> [As some people couldn't read it, I've also replaced the diag quoted
{ >>> in the thread below with narrower ASCII-art to better survive word
{ >>> wrap]
{ >>>
{ >>> Cheers
{ >>>
{ >>>
{ >>> Bob
{ >>>
{ >>> At 07:27 19/08/2009, [email-masked] wrote:
{ >>>
{ >>> Hi Bob,
{ >>>
{ >>> I agree to your suggestion to "scrub (ii) and only have (i)..[and
{ >>> that] we should list classes that might be appropriate to associate
{ >>> with PCN marking."
{ >>>
{ >>> Regards,
{ >>>
{ >>> Ruediger
{ >>>
{ >>> ----------------------------------------------------------------------
{ --
{ >>>
{ >>>
{ >>> *From:* Bob Briscoe [ mailto:[email-masked]]
{ >>> *Sent:* Tuesday, August 18, 2009 7:37 PM
{ >>> *To:* Geib, Rüdiger; [email-masked]
{ >>> *Cc:* [email-masked]
{ >>> *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
{ >>>
{ >>> Ruediger,
{ >>>
{ >>> The draft as it stands holds two inconsistent opinions:
{ >>> i) "
{ >>>
{ >>> the aim is for PCN to re-use existing DSCPs
{ >>>
{ >>>
{ >>> " (S.4.3.1)
{ >>> ii) the second half of Appx A.1, repeated below.
{ >>>
{ >>> Similarly, your posting, talks about:
{ >>> i) applying PCN to existing DSCPs
{ >>> ii) reserving DSCPs for PCN.
{ >>>
{ >>> I believe we should scrub (ii) and only have (i). In place of ii) we
{ >>> should list the classes that might be appropriate to associate with
{ >>> PCN marking.
{ >>>
{ >>> In other words, we should only say that an operator _applies_ PCN
{ >>> marking to certain existing DSCPs.
{ >>>
{ >>> No-one needs any additional DSCPs to enable PCN marking. Otherwise
{ >>> that would waste DSCPs just to get a different marking behaviour for
{ >>> packets requiring the same scheduling behaviour as a pre-existing
{ >>> DSCP. The non-wasteful way to do this is to use one DSCP for a
{ >>> certain scheduling behaviour, but set the ECN field to a non-zero
{ >>> value to turn on PCN marking (S.4.3.1).
{ >>>
{ >>> [In MPLS, as there is no ECN field, the efficient way is different.
{ >>> Then RFC5129 describes how you would do it.]
{ >>>
{ >>> To be absolutely sure it's clear what I mean, here's an example:
{ >>>
{ >>>
{ >>> hi stat mux subnet
{ >>> ___________________
{ >>> | same |
{ >>> | marking |
{ >>> | _____ ____:___ |
{ >>> | | || ||
{ >>> --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
{ >>> | | || ||
{ >>> --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
{ >>> | | ||________||
{ >>> | | | |
{ >>> --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
{ >>> | |_____| |
{ >>> | _____ |
{ >>> | | | |
{ >>> --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
{ >>> | | | |
{ >>> --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
{ >>> | |_____| |
{ >>> | : |
{ >>> | same |
{ >>> | scheduling |
{ >>> | (BA) |
{ >>> |___________________|
{ >>>
{ >>>
{ >>> - The text on each flow shows the DSCP-ECN combination used for that
{ >>> segment
{ >>> - The boxes around DSCPA/B/C and around DSCPD/E represent the same
{ >>> scheduling behaviour applied to multiple DSCPs in the aggregated
{ >>> region (a behaviour aggregate).
{ >>> - The box around NM for the first two flows represents the same
{ >>> marking behaviour (PCN) applied to multiple DSCPs.
{ >>> - The flows keep the same DSCP* along their whole path, so when they
{ >>> pop out into the lo-stat-mux region on the other side, the DSCP is
{ >>> preserved.
{ >>> - In practice, traffic might be tunnelled across the hi-stat mux
{ >>> region, and at the same time common scheduling behaviours might be
{ >>> mapped to a single DSCP in the outer headers. The diagram merely
{ >>> shows everything can be done without tunnelling or layering.
{ >>>
{ >>> * Note: For some non-standardised DSCPs, the DSCP might not actually
{ >>> stay the same along the whole path. It might be mapped to local
{ >>> DSCPs that are each used for the same class at different points
{ >>> along the path.
{ >>>
{ >>>
{ >>> Here's a copy of the 2nd half of Appx A.1, that I think needs to be
{ >>> removed (sorry, I know I'm a co-author, but...):
{ >>> " The choice of which DSCP is most suitable for
{ >>> a given PCN-domain is dependant on the nature of the
{ >>> traffic
{ >>> entering
{ >>> that domain and the link rates of all the links making up
{ >>> that
{ >>> domain. In PCN-domains with uniformly high link
{ >>> rates,
{ >>> the
{ >>> appropriate DSCPs would currently be those for the Real
{ >>> Time
{ >>> Traffic
{ >>> Class
{ >>> [RFC5127 <http://tools.ietf.org/html/rfc5127>]. If the
{ >>> PCN domain includes lower speed links it
{ >>> would also be appropriate to use the DSCPs of the other
{ >>> traffic
{ >>> classes that
{ >>> [
{ >>> <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-
{ Voice-Admit>
{ >>>
{ >>> Voice-Admit
{ >>> <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-04#ref-
{ Voice-Admit>]
{ >>> defines for use with admission control,
{ >>> such as the three video classes CS4, CS3 and AF4 and the
{ >>> Admitted
{ >>> Telephony Class. The PCN working group will maintain
{ >>> a
{ >>> list of PCN-
{ >>> compatible Diffserv Codepoints.
{ >>>
{ >>>
{ >>> "
{ >>>
{ >>> At 08:55 18/08/2009, [email-masked] wrote:
{ >>>
{ >>> Toby,
{ >>>
{ >>> PCN should express to the IANA, whether one or more new DSCP is
{ >>> required to operate or carry out experiments on PCN.
{ >>>
{ >>> As soon as IANA maintains a list of DSCPs for any purpose, this
{ >>> will have the status of a standard.
{ >>>
{ >>> "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs
{ >>> per traffic class (DSCP bit 0-2, let's call them traffic class
{ >>> in this email) for PCN, that's 32 DSCPs in all.
{ >>>
{ >>> If possible, PCN should limit the number of traffic classes,
{ >>> where to apply PCN.
{ >>>
{ >>> I don't think PCN will be applied in traffic classes 0 and 6.
{ >>>
{ >>> I'd expect PCN to be used within traffic classes 5 and 4,
{ >>> may be also 3 or 2.
{ >>>
{ >>> Traffic classes 1 and 7 may be excluded too.
{ >>>
{ >>> The above clearly expresses personal views, but informational
{ >>> RFC5127 to some extent backs these personal views.
{ >>>
{ >>> I'm aware that PCN WG shouldn't standardise traffic class usage
{ >>> or come close to that. I however want to avoid repeating the biggest
{ >>> flaw of the AF specification, which in my eyes is to reserve
{ >>> 12 DSCPs for 4 traffic classes.
{ >>>
{ >>> Regards,
{ >>>
{ >>> Ruediger
{ >>>
{ >>>
{ >>>
{ >>> -----Original Message-----
{ >>> From: [email-masked] [ mailto:[email-masked]] On Behalf
{ >>> Of [email-masked]
{ >>> Sent: Friday, August 14, 2009 3:06 PM
{ >>> To: [email-masked]; [email-masked]
{ >>> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
{ >>>
{ >>> Hi Lars,
{ >>>
{ >>> Sorry not to get back to you earlier - been busy at work so this
{ >>> went on
{ >>> a back-burner for a few days.
{ >>>
{ >>> The original intention of having registration was to avoid confusion
{ >>> during any early experimental adoption of PCN however that could be
{ >>> done
{ >>> purely unofficially by having a list of DSCPs on the IETF wiki and
{ just
{ >>> politely asking developers to consult it and add any new ones they are
{ >>> using. But there will need in future to be a process to formally
{ >>> register certain standards (pool 1) DSCPs as PCN-compatible since this
{ >>> effectively replaces ECN as the default behaviour for such DSCPs. So
{ my
{ >>> suggestion is:
{ >>>
{ >>> Change the IANA section to say something along the following lines (I
{ >>> will get IANA assistance with crafting exact text):
{ >>>
{ >>> "IANA will be asked to set up a registry of PCN-compatible Diffserv
{ >>> codepoints. The decision as to whether to enable PCN for a given pool
{ 1
{ >>> codepoint must be made by the appropriate IETF Transport Area Working
{ >>> Group (TSVWG?) which will then request IANA to add this to the
{ >>> registry."
{ >>>
{ >>> Clarify at start of A.1 that the decision of which DSCPs to apply
{ >>> PCN to
{ >>> has to be made by TSVWG and is separate to this document which just
{ >>> defines the process and the encoding.
{ >>>
{ >>> Change the last sentence of A.1 to "IANA will maintain a list of
{ >>> PCN-compatible Diffserv Codepoints."
{ >>>
{ >>> Would this cover things appropriately? I did wonder about asking
{ >>> IANA to
{ >>> maintain the experimental registry but I am not sure if they are
{ >>> able to
{ >>> do that sort of thing? If so the following could be added to the IANA
{ >>> section:
{ >>>
{ >>> "During the early stages of adoption it is envisaged that PCN will be
{ >>> used experimentally using pool 2 or 3 DSCPs (experimental or local
{ >>> use).
{ >>> Whilst these DSCPs are not controlled by IANA normally, a request will
{ >>> be made to maintain a list of PCN experiments along with the DSCPs
{ >>> these
{ >>> experiments are using."
{ >>>
{ >>> Once I get the nod from WG I will release a new version of the I-D
{ with
{ >>> these updates...
{ >>>
{ >>> Toby
{ >>>
{ >>> > -----Original Message-----
{ >>> > From: [email-masked] [ mailto:[email-masked]] On
{ >>> Behalf Of
{ >>> > Lars Eggert
{ >>> > Sent: 14 August 2009 12:27
{ >>> > To: [email-masked]
{ >>> > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
{ >>> >
{ >>> > Hi,
{ >>> >
{ >>> > I'm waiting to hear from the authors/WG.
{ >>> >
{ >>> > Lars
{ >>> >
{ >>> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
{ >>> >
{ >>> > > Hi,
{ >>> > >
{ >>> > > this document is ready, except for one issue:
{ >>> > >
{ >>> > > Section 7., paragraph 1:
{ >>> > >> This document makes no direct request to IANA. However this
{ >>> > > document
{ >>> > >> allows for a set of Diffserv Codepoints to be assigned different
{ >>> > > ECN
{ >>> > >> semantics within a controlled domain as described in [RFC4774].
{ >>> A
{ >>> > >> list of such DSCPs will be maintained by the PCN working group.
{ >>> > >
{ >>> > > DISCUSS: This text isn't aligned with appendix A.1. The text here
{ >>> > > says
{ >>> > > "the WG will maintain a list of DSCPs that are OK", while the
{ >>> > > beginning of appendix A.1 says "the WG decided to not define with
{ >>> > > which DSCPs PCN can be used" (but then the end of A.1 talks about
{ >>> > > maintaining a list again.) Which is it? If there is to be a list,
{ >>> > > you
{ >>> > > need to create an IANA registry, write management procedures for
{ >>> it
{ >>> > > (see RFC5226) and populate it with some initial values. (WGs are
{ >>> > > ephemeral, which is why the PCN WG can't be the maintainer of this
{ >>> > > list, IANA has to be.) If you want to leave it fully open for
{ >>> > > deployments, you need to remove this confusion from the text.
{ >>> > >
{ >>> > > Lars
{ >>> > >
{ >>> > >
{ >>> > > Nits:
{ >>> > >
{ >>> > > Section 4., paragraph 3:
{ >>> > >> to prevent future compatability issues.
{ >>> > >
{ >>> > > Nit: s/compatability/compatibility/
{ >>> > >
{ >>> > >
{ >>> > > Section 4.2., paragraph 1:
{ >>> > >> that is guaranteeed to be copied down into the inner header upon
{ >>> > >
{ >>> > > Nit: s/guaranteeed/guaranteed/
{ >>> > >
{ >>> > >
{ >>> > > Section 6., paragraph 1:
{ >>> > >> always copy the CE codepoint from teh outer header into the inner
{ >>> > >
{ >>> > > Nit: s/teh/the/
{ >>> > >
{ >>> > >
{ >>> > > Section 6., paragraph 2:
{ >>> > >> header in decapsulation (unless the inner packet is not-ECT).
{ >>> > > If an
{ >>> > >> operator it is essential that any operator wishing to allow ECN
{ >>> to
{ >>> > >> exist end-to-end ensures there are no tunnel end-points within
{ >>> the
{ >>> > >> PCN-domain.
{ >>> > >
{ >>> > > "If an operator it is essential that any operator..." - wording
{ >>> > >
{ >>> > >
{ >>> > > Section 12., paragraph 0:
{ >>> > >> 12. References
{ >>> > >
{ >>> > > Should be updated; see idnits report.
{ >>> > >
{ >>> > >
{ >>> > > Appendix A., paragraph 2:
{ >>> > >> a given PCN-domain is dependant on the nature of the traffic
{ >>> > > entering
{ >>> > >
{ >>> > > Nit: s/dependant/dependent/
{ >>> > >
{ >>> > > <smime.p7s><ATT00001.txt>
{ >>>
{ >>> _______________________________________________
{ >>> PCN mailing list
{ >>> [email-masked]
{ >>> https://www.ietf.org/mailman/listinfo/pcn
{ >>> _______________________________________________
{ >>> PCN mailing list
{ >>> [email-masked]
{ >>> https://www.ietf.org/mailman/listinfo/pcn
{ >>>
{ >>> ----------------------------------------------------------------------
{ --
{ >>>
{ >>>
{ >>> _______________________________________________
{ >>> PCN mailing list
{ >>> [email-masked]
{ >>> https://www.ietf.org/mailman/listinfo/pcn
{ >>>
{ >>
{ >> --
{ >> Dr. Michael Menth, Assistant Professor
{ >> University of Wuerzburg, Institute of Computer Science
{ >> Am Hubland, D-97074 Wuerzburg, Germany, room B206
{ >> phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
{ >> mailto:[email-masked]
{ >> http://www3.informatik.uni-wuerzburg.de/research/ngn
{ 
{ --
{ Dr. Michael Menth, Assistant Professor
{ University of Wuerzburg, Institute of Computer Science
{ Am Hubland, D-97074 Wuerzburg, Germany, room B206
{ phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
{ mailto:[email-masked]
{ http://www3.informatik.uni-wuerzburg.de/research/ngn
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Aug 2009 12:35:37 +0200

Hi,

this sounds like a reasonable way forward.

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Aug 2009 11:59:01 +0100

Phil, Tho you're correct, I think Michael's point 
was about excessive use of DSCPs.

Michael, I agree (and this has been said in the 
relevant encoding drafts, AFAIK). Ie. A PCN 
encoding that uses 2 DSCPs will need a second 
DSCP for every DSCP it is applied to. If it 
applies to n DSCPs, it will consume 2n DSCPs.

Bob

At 10:45 19/08/2009, [email-masked] wrote:
>Yes, I think any of the extended pcn encodings 
>that uses 2 dscps needs to say something about 
>the scheduling behaviour of the 2 dscps. The 
>obvious thing is that they both map to the same 
>scheduling PHB (actually, first guess is that 
>this is the only thing that makes sense)
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Aug 2009 12:13:25 +0100

Lars, Toby,

Yup, seems the way to go.

Concerning:
>"explain what we would expect
>apply to (either existing or new ones). "

I don't see this as a big issue. It's just advice (informational 
appendix). If an operator applies PCN to a DSCP that isn't on the 
list, AFAIK it doesn't create any interworking problem that the IETF 
needs to worry about (noting that the charter says we have to keep 
interconnection in mind). So we don't need a process for the IETF to 
_approve_ the use of PCN for a DSCP not on the list.

Already some operators choose to apply admission control to a class 
while others don't. Introducing PCN to the RFC series simply adds 
another choice of mechanism with which to do admission control. But 
that doesn't create any more of an interworking problem than there 
was originally with operators choosing which classes they do 
admission control for. Even if they do PCN interconnect purely in the 
data plane, without back-to-back edge gateways at the interconnect, 
it doesn't create any greater interworking problem than they already have.

They already have to agree between themselves if they want to do 
inter-domain admission control for a class. And they have to agree 
the mechanism. So surely PCN is just added to that conversation as 
another mechanism choice.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Aug 2009 13:51:13 +0100

Toby,

At 09:39 19/08/2009, [email-masked] wrote:

That ASCII art is still
unreadable because (for me at least) it is getting displayed in a
variable-width font (Times New Roman to be exact). I ended up having to
convert it to Courier to be able to see what you meant…

The Tao of email says that's your problem. I sent it as plain text (and
even if I didn't it would have been Courier New (fixed)).

I am in the process of drafting a reply setting out the background to
this confusion and hopefully solving it. In the meantime there seems to
be a consensus that the way ahead is to recommend PCN as suitable for 1
or more EXISTING DSCPs (which means we need to decide which ones…). But
that still leaves the question of whether we need to say something about
what needs to happen in the future if someone (say Fred Baker) wants to
add PCN to a new DSCP.

Ruediger has suggested some. Can you check them off against those that
Fred discusses in voice-admit. That should give a decent list.

Bob

Toby

Cc: [email-masked]

Subject: RE: [PCN] AD review:
draft-ietf-pcn-baseline-encoding-04

Ruediger,

Great.

Cheers

Bob

Hi Bob,

I agree to your suggestion to "scrub (ii) and only have (i)..[and
that] we should list classes that might be appropriate to associate with
PCN marking."

Regards,

Ruediger

From: Bob Briscoe
[

Cc: [email-masked]

Ruediger,

i) "

" (S.4.3.1)

hi stat mux subnet

___________________

|
same   |

|           marking
|

|   _____  ____:___ |

|  |
||        ||

|  |
||        ||

|  |     ||________||

|  |
|
|--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--

|  |_____|
|

|
_____           |

|  |
|          |

|  |
|          |

|  |_____|
|

|
:
|

|
same
|

| scheduling        |

|
(BA)
|

|___________________|

Here's a copy of the 2nd half of Appx A.1, that I think needs to
be

"  The choice of which DSCP is most suitable
for

a given PCN-domain is dependant on the nature of
the

traffic

entering

that domain and the link rates of all the links making
up

that

domain.  In PCN-domains with uniformly high
link

rates,

the

appropriate DSCPs would currently be those for the
Real

Time

Traffic

Class

[RFC5127].  If
the

would also be appropriate to use the DSCPs of the
other

traffic

classes that

[

such as the three video classes CS4, CS3 and AF4 and
the

Admitted

Telephony Class.  The PCN working group will
maintain

a

list of PCN-

"

Toby,

where to apply PCN.

may be also 3 or 2.

Regards,

Ruediger

-----Original Message-----

From: [email-masked] [
mailto:[email-masked]] On
Behalf Of [email-masked]

Hi Lars,

suggestion is:

registry."

section:

experiments are using."

these updates...

Toby

> From: [email-masked] [
mailto:[email-masked]] On
Behalf Of

described in [RFC4774].

A

to be a list,

procedures for

it

wishing to allow ECN

to

end-points within

the

PCN mailing list

[email-masked]

PCN mailing list

[email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 14:27:39 +0100

Leaving aside ASCII art.

>From Ruediger's list below and Fred's draft the following seems like a possible list of DSCPs that might reasonably employ PCN marking:

CS2, CS3, CS4, CS5, AF4.

Phil in an earlier email suggested EF as well.

Does that seem like a sensible list? Should we actually play it safe and reduce it slightly?

Toby

From: Briscoe,RJ,Bob,XVR9 BRISCORJ R 
Sent: 19 August 2009 13:51
To: Moncaster,T,Toby,DER3 R; [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Toby,

The Tao of email says that's your problem. I sent it as plain text (and even if I didn't it would have been Courier New (fixed)). 

Ruediger has suggested some. Can you check them off against those that Fred discusses in voice-admit. That should give a decent list.

Bob

Toby

Ruediger,

Great.

Cheers

Bob

Hi Bob,

Regards,
 
Ruediger

From: Bob Briscoe [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

" (S.4.3.1)

                   hi stat mux subnet
                   ___________________
                  |            same   |
                  |           marking |
                  |   _____  ____:___ |
                  |  |     ||        ||
                  |  |     |          |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--

traffic

entering

that

rates,

the

Time

Traffic

   Class

[RFC5127 <http://tools.ietf.org/html/rfc5127> ].  If
the

traffic

   classes that

 

Admitted

a

list of PCN-

"

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [ mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 14, 2009 3:06 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Toby

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 15:55:57 +0200

Toby,
 
my mail referred to MPLS TCs, DSCP bits 0-2. Which is to say, I included EF and AF2-4. AF may be limited to the AFn1 classes. If that creates to much controversy, PCN may express something like AF classes are for further study (so that they don't seem to be excluded).
 
By the way, I'm interested in learning more about best current provider practice, especially on CS/AF classes 1-4 and their treatment in the backbone. 
- whether three colour marking is applied at all
- whether separate drop levels are offered as a service supported by an IP backbone (or limited to edges only), and if separate drop levels, how many.
- or whether only DSCP bits 0-2 are evaluated for backbone transport (let's call them precedence bits)
- further options
Carrier representatives interested may contact me privately. I'd like to learn whether there's sense and interest in an interconnection cookbook (an informational document written by provider representatives).
 
Regards,
 
Ruediger

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2009 3:28 PM
To: [email-masked]; Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Leaving aside ASCII art.

CS2, CS3, CS4, CS5, AF4.

Toby

Toby,

Bob

Toby

Ruediger,

Great.

Cheers

Bob

Hi Bob,

Regards,
 
Ruediger

  _____  

Ruediger,

" (S.4.3.1)

                   hi stat mux subnet
                   ___________________
                  |            same   |
                  |           marking |
                  |   _____  ____:___ |
                  |  |     ||        ||

traffic

entering

that

rates,

the

Time

Traffic

   Class

traffic

   classes that

 

Admitted

a

list of PCN-

"

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [ mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 14, 2009 3:06 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Toby

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Aug 2009 16:55:36 +0100

Toby,

At 14:27 19/08/2009, [email-masked] wrote:

Leaving aside ASCII art.

From Ruediger’s list below and Fred’s draft the following seems like a
possible list of DSCPs that might reasonably employ PCN marking:

CS2, CS3, CS4, CS5, AF4.

From your list, I strongly suggest you don't include:

CS2     Ops, Admin & Mgmt
(not predictably streamed enough for AC)

CS5     Call signalling
(ditto)

In addition AF3 /might/ be admission controlled.

Suggested text to replace the end of Appx A.1:

============================================================================

It is recommended to use admission control for the following service
classes listed with their recommended PHBs
[I-D.ietf-tsvwg-admitted-realtime-dscp][RFC4594]:

- Telephony (*)

- Real-time interactive (CS4)

- Broadcast Video (CS3)

- Multimedia Conferencing (AF4)

*Note: The PHB of the the telephony service class is currently EF, but
[I-D.ietf-tsvwg-admitted-realtime-dscp] proposes a new PHB called
VOICE-ADMIT. It has identical scheduling behaviour to EF, but it is for
use with admission control mechanisms in the network, rather than at the
application layer. If this draft progresses on the standards track,
VOICE-ADMIT rather than EF would become the appropriate Telephony PHB to
which PCN marking would be applied.

PCN marking is intended to provide a scalable admission control mechanism
for traffic with a high degree of statistical multiplexing. PCN marking
would therefore be appropriate to apply to traffic in the above classes,
but only  within a PCN region containing highly aggregated
traffic.

In such cases, the above service classes may well all be subject to a
single forwarding treatment (a treatment aggregate [RFC5127]). However,
this does not imply all such IP traffic would necessarily be identified
by one DSCP - each service class might keep a distinct DSCP within the
highly aggregated region [RFC5127].

Additional service classes may be defined for which admission control is
appropriate, whether through some future standards action or through
local use by certain operators, e.g. the Multimedia Streaming service
class (AF3). This document does not preclude the use of PCN in more cases
than those listed above.

The above discussion is informative not normative, as operators are
ultimately free to decide whether to use admission control for certain
service classes and whether to use PCN as their mechanism of choice.

==============================================================================

Bob

Does that seem like a sensible list? Should we actually play it safe and
reduce it slightly?

Toby

Cc: [email-masked]

Toby,

That ASCII art is still unreadable because (for me at least) it is
getting displayed in a variable-width font (Times New Roman to be exact).
I ended up having to convert it to Courier to be able to see what you
meant…

Bob

Toby

Cc: [email-masked]

Ruediger,

Great.

Cheers

Bob

Hi Bob,

Regards,

Ruediger

From: Bob Briscoe [

Cc: [email-masked]

Ruediger,

i) "

" (S.4.3.1)

hi stat mux subnet

___________________

|
same   |

|           marking
|

|   _____  ____:___ |

|  |
||        ||

|  |
||        ||

|  |     ||________||

|  |
|

|  |_____|
|

|
_____           |

|  |
|          |

|  |
|          |

|  |_____|
|

|
:
|

|
same
|

| scheduling        |

|
(BA)
|

|___________________|

Here's a copy of the 2nd half of Appx A.1, that I think needs
to

be

"  The choice of which DSCP is most
suitable

for

a given PCN-domain is dependant on the nature
of

the

traffic

entering

that domain and the link rates of all the links
making

up

that

domain.  In PCN-domains with uniformly
high

link

rates,

the

appropriate DSCPs would currently be those for
the

Real

Time

Traffic

Class

[RFC5127].
If

the

would also be appropriate to use the DSCPs of
the

other

traffic

classes that

[

such as the three video classes CS4, CS3 and AF4
and

the

Admitted

Telephony Class.  The PCN working group
will

maintain

a

list of PCN-

"

Toby,

where to apply PCN.

may be also 3 or 2.

Regards,

Ruediger

-----Original Message-----

Hi Lars,

suggestion is:

registry."

section:

experiments are using."

these updates...

Toby

described in [RFC4774].

A

to be a list,

procedures for

it

wishing to allow ECN

to

end-points within

the

PCN mailing list

[email-masked]

PCN mailing list

[email-masked]

---

From: Michael Menth <[email-masked]>
Date: Wed, 19 Aug 2009 18:44:53 +0200

Hi,

PCN means admission control in practice. If we have non-PCN and PCN 
traffic in the same BA, that does not sound very reasonable from my 
perspective, because it just prevent PCN traffic hitting the QoS of 
non-PCN traffic but not vice-versa. But that was not the ideo of PCN, 
right? That could be another constraint for usable DSCPs.

Regards,

Michael

Bob Briscoe schrieb:
>> From Ruediger’s list below and Fred’s draft the following seems like 
>> a possible list of DSCPs that might reasonably employ PCN marking:
>>
>> CS2, CS3, CS4, CS5, AF4.
>
> CS2 Ops, Admin & Mgmt (not predictably streamed enough for AC)
> CS5 Call signalling (ditto)
>
> VOICE-ADMIT. It has identical scheduling behaviour to EF, but it is 
> for use with admission control mechanisms in the network, rather than 
> at the application layer. If this draft progresses on the standards 
> track, VOICE-ADMIT rather than EF would become the appropriate 
> Telephony PHB to which PCN marking would be applied.
>
> PCN marking is intended to provide a scalable admission control 
> mechanism for traffic with a high degree of statistical multiplexing. 
> PCN marking would therefore be appropriate to apply to traffic in the 
> above classes, but only within a PCN region containing highly 
> aggregated traffic.
>
> single forwarding treatment (a treatment aggregate [RFC5127]). 
> However, this does not imply all such IP traffic would necessarily be 
> identified by one DSCP - each service class might keep a distinct DSCP 
> within the highly aggregated region [RFC5127].
>
> Additional service classes may be defined for which admission control 
> is appropriate, whether through some future standards action or 
> through local use by certain operators, e.g. the Multimedia Streaming 
> service class (AF3). This document does not preclude the use of PCN in 
> more cases than those listed above.
>
>> *Sent:* 19 August 2009 13:51
>> *To:* Moncaster,T,Toby,DER3 R; [email-masked]
>> *Cc:* [email-masked]
>> The Tao of email says that's your problem. I sent it as plain text 
>> (and even if I didn't it would have been Courier New (fixed)).
>>
>>
>>
>> Ruediger has suggested some. Can you check them off against those 
>> that Fred discusses in voice-admit. That should give a decent list.
>>
>>
>> Bob
>>
>>
>>
>> Toby
>>
>> *From:* Bob Briscoe [ 
>> <mailto:[email-masked]>mailto:[email-masked]]
>> [RFC5127 <http://tools.ietf.org/html/rfc5127>]. 
>> If
>>
>>
>> the
>>
>>
>>

---

From: <[email-masked]>
Date: Thu, 20 Aug 2009 08:57:25 +0200

Bob,
 
I largely agree to what you propose below. From the point of view 
of a carrier operating an MPLS LDP based backbone, the following 
situation arises:
- the carrier may offer public telephony. This service is fully 
  controlled by the carrier and if this carrier deploys any 
  network based admission control, it doesn't matter, whteher the 
  DSCP is EF or Voice admit. It will however be one of both only.
- the same carrier may offer VPN services with EF transport. The 
  interface to access a VPN may be Ethernet, IP or MPLS.
- if such a carrier supports four traffic classes in the MPLS 
  backbone, Voice admit and EF are likely to be transported in 
  the same queue.
- there's one MPLS TC available for not congested traffic and 
  one indicating congestion experienced. As all in all only 8 TCs 
  are available, this is a scarce resource making it unlikely 
  to get one MPLS TC for EF, one for Voice_admit and another 
  one for Voice_admit_congestion_experienced.
 
Carriers usually have little control about how VPN customers use EF.
 
While the above may sound disappointing, I don't look at it to 
prevent deployment of PCN or other solutions offering network 
based admission control. Diffserv isn't a greenfield approach, 
so dealing with existing environments is a natural provider task. 
Traffic levels are an issue. VPN EF traffic may in future 
contribute a small percentage of load as compared to public 
VoIP traffic. But I'm not having any numbers, that's an 
assumption only.
 
Separation of EF and Voice_admit may only exist on IP 
level - but I don't want to discuss this now. PCN to me 
is to far from being ready for deployment.

Regards,
 
Ruediger

  _____  

From: Bob Briscoe [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2009 5:56 PM
To: [email-masked]; Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Toby,

Leaving aside ASCII art.

CS2, CS3, CS4, CS5, AF4.

============================================================================
It is recommended to use admission control for the following service classes listed with their recommended PHBs [I-D.ietf-tsvwg-admitted-realtime-dscp][RFC4594]:
- Telephony (*)
- Real-time interactive (CS4)
- Broadcast Video (CS3)
- Multimedia Conferencing (AF4)

*Note: The PHB of the the telephony service class is currently EF, but [I-D.ietf-tsvwg-admitted-realtime-dscp] proposes a new PHB called VOICE-ADMIT. It has identical scheduling behaviour to EF, but it is for use with admission control mechanisms in the network, rather than at the application layer. If this draft progresses on the standards track, VOICE-ADMIT rather than EF would become the appropriate Telephony PHB to which PCN marking would be applied. 

PCN marking is intended to provide a scalable admission control mechanism for traffic with a high degree of statistical multiplexing. PCN marking would therefore be appropriate to apply to traffic in the above classes, but only  within a PCN region containing highly aggregated traffic.

In such cases, the above service classes may well all be subject to a single forwarding treatment (a treatment aggregate [RFC5127]). However, this does not imply all such IP traffic would necessarily be identified by one DSCP - each service class might keep a distinct DSCP within the highly aggregated region [RFC5127].

Additional service classes may be defined for which admission control is appropriate, whether through some future standards action or through local use by certain operators, e.g. the Multimedia Streaming service class (AF3). This document does not preclude the use of PCN in more cases than those listed above. 

The above discussion is informative not normative, as operators are ultimately free to decide whether to use admission control for certain service classes and whether to use PCN as their mechanism of choice.
==============================================================================

Bob

 
Toby

Toby,

 

Bob

Toby

Ruediger,

Great.

Cheers

Bob

Hi Bob,

Regards,
 
Ruediger

  _____  

Ruediger,

" (S.4.3.1)

                   hi stat mux subnet
                   ___________________
                  |            same   |
                  |           marking |
                  |   _____  ____:___ |
                  |  |     ||        ||

to

be

suitable

for

of

the

traffic

entering

making

up

that

high

link

rates,

the

the

Real

Time

Traffic

   Class

[RFC5127 <http://tools.ietf.org/html/rfc5127> ]. 

If

the

the

other

traffic

   classes that

[

and

the

Admitted

will

maintain

a

list of PCN-

"

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [ mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 14, 2009 3:06 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Toby