[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
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
Toby,
At 14:27 19/08/2009, toby.moncaster at bt.com 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
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