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; Ruediger.Geib at telekom.de
Cc: pcn at ietf.org
Subject: RE: [PCN] AD review:
draft-ietf-pcn-baseline-encoding-04
Toby,
At 09:39 19/08/2009, toby.moncaster at bt.com 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
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].
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