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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
{ Michael Menth
{ Sent: 19 August 2009 10:34
{ To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ Cc: pcn at ietf.org
{ 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
{ >>
{ >>
{ >>
{ >> toby.moncaster at bt.com 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:* Ruediger.Geib at telekom.de; Moncaster,T,Toby,DER3 R
{ >>> *Cc:* pcn at ietf.org
{ >>> *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, Ruediger.Geib at telekom.de 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:rbriscoe at jungle.bt.co.uk]
{ >>> *Sent:* Tuesday, August 18, 2009 7:37 PM
{ >>> *To:* Geib, Rüdiger; toby.moncaster at bt.com
{ >>> *Cc:* pcn at ietf.org
{ >>> *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, Ruediger.Geib at telekom.de 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: pcn-bounces at ietf.org [ mailto:pcn-bounces at ietf.org] On Behalf
{ >>> Of toby.moncaster at bt.com
{ >>> Sent: Friday, August 14, 2009 3:06 PM
{ >>> To: lars.eggert at nokia.com; pcn at ietf.org
{ >>> 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: pcn-bounces at ietf.org [ mailto:pcn-bounces at ietf.org] On
{ >>> Behalf Of
{ >>> > Lars Eggert
{ >>> > Sent: 14 August 2009 12:27
{ >>> > To: pcn at ietf.org
{ >>> > 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
{ >>> PCN at ietf.org
{ >>> https://www.ietf.org/mailman/listinfo/pcn
{ >>> _______________________________________________
{ >>> PCN mailing list
{ >>> PCN at ietf.org
{ >>> https://www.ietf.org/mailman/listinfo/pcn
{ >>>
{ >>> ----------------------------------------------------------------------
{ --
{ >>>
{ >>>
{ >>> _______________________________________________
{ >>> PCN mailing list
{ >>> PCN at ietf.org
{ >>> 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:menth at informatik.uni-wuerzburg.de
{ >> 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:menth at informatik.uni-wuerzburg.de
{ http://www3.informatik.uni-wuerzburg.de/research/ngn
{
{ _______________________________________________
{ PCN mailing list
{ PCN at ietf.org
{ https://www.ietf.org/mailman/listinfo/pcn