[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
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
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, 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