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

[<toby.moncaster at bt.com>]

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

> -----Original Message-----
> From: Michael Menth [mailto:menth at informatik.uni-wuerzburg.de]
> Sent: 19 August 2009 09:52
> To: Moncaster,T,Toby,DER3 R
> Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; Ruediger.Geib at telekom.de;
> pcn at ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
> 
> 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