As a part of this specification, the overall
rate of the PCN coloured traffic is metered on
every link in the domain, and these packets are
appropriately marked when certain configured rates are exceeded.
This document specifies how such marks are
encoded into the IP header by re-using the
Explicit Congestion Notification (ECN)
codepoints within this controlled domain. The
baseline encoding described here provides for
only two PCN encoding states, Not-marked and PCN-marked.
Please maintain the notion of "overall rate of
PCN traffic" or "PCN coloured traffic" which is
being metered in the version of abstract you go on with.
Regards,
Ruediger
-----Original Message-----
From: toby.moncaster at bt.com
[mailto:toby.moncaster at bt.com] Sent: Wednesday, August 26, 2009 1:13 PM
To: menth at informatik.uni-wuerzburg.de; Geib, Rüdiger
Cc: bob at homefarmparham.co.uk; pcn at ietf.org
Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART
Review ofdraft-ietf-pcn-baseline-encoding-05
So would the following sound better? :
Pre-Congestion Notification (PCN) is a
metering and marking scheme that protects
the quality of service (QoS) of inelastic
flows within a Diffserv domain. The overall
rate of the traffic is metered on
every link in the domain, and packets are appropriately marked when certain
configured rates are exceeded. Boundary nodes can measure the level
of marking and thus make decisions about whether to admit or block a
new flow request, and (in abnormal circumstances) whether to
terminate some of the existing flows, thereby protecting the QoS of
previously admitted flows. This document specifies how such marks
are encoded into the IP header by re-using the Explicit Congestion
Notification (ECN) codepoints within this controlled domain. The
baseline encoding described here provides for only two PCN encoding
states, Not-marked and PCN-marked.
Just for clarity here was the earlier version I proposed:
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
The overall rate of the traffic is metered on every link in the
domain, and packets are appropriately marked when certain
configured rates are exceeded. Boundary nodes can measure the level
of marking and thus make decisions about whether to admit or block a
new flow request, and (in abnormal circumstances) whether to
terminate some of the existing flows, thereby protecting the QoS of
previously admitted flows. This document specifies how such marks
are encoded into the IP header by re-using the Explicit Congestion
Notification (ECN) codepoints within this controlled domain. The
baseline encoding described here provides for only two PCN encoding
states, Not-marked and PCN-marked.
I personally disagree with Tom's suggestion to
add PCN to all the defined terms (e.g. PCN
flow, PCN traffic) - that is fine within the
body of the document but in this abstract we
should avoid using any terms that readers
won't be already familiar with.
-----Original Message-----
From: Michael Menth [mailto:menth at informatik.uni-wuerzburg.de]
Sent: 26 August 2009 08:46
To: Ruediger.Geib at telekom.de
Cc: bob at homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn at ietf.org
Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
baseline-encoding-05
Hi all,
Rüdiger touches an issue that I also feel is not optimally solved in
the
current abstract. The objective of PCN is provide marking information
to
egress node and the objective of admission control and flow termination
is to protect QoS. I use the following short explanation for PCN. Maybe
this idea could be added to the current abstract.
Pre-congestion notification (PCN) is a metering and marking scheme for
Differentiated Services (DiffServ) IP networks which provides egress
nodes with information about load conditions inside the network
\cite{RFC5559}. This information is used for admission control and flow
termination to support quality of service (QoS) for admitted inelastic
realtime flows that are carried with prioritization within the DiffServ
domain.
This document specifies how nodes encode the marking information in the
IP header by re-using the Explicit Congestion Notification (ECN)
codepoints within a controlled DiffServ domain. The baseline encoding
described here provides for only two PCN encoding states which are
not-marked and PCN-marked.
Regards,
Michael
Ruediger.Geib at telekom.de schrieb:
Toby, Bob
if the abstract is to mention PCN functionalities not defined within
this document in a rather simplified way, would the purpose of PCN
be to enable a Diffserv domain to support measurement based
admission control as defined by PCN architecture?
Regards,
Ruediger
-----Original Message-----
From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
Bob Briscoe
Sent: Tuesday, August 25, 2009 8:42 PM
To: toby.moncaster at bt.com; pcn at ietf.org
Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
baseline-encoding-05
Toby,
I think this isn't just good for a casual reader, but it is actually
still correct and doesn't require defining PC-domain (which is just
the Diffserv domain once the described measures - the PDB - have been
put in place).
Bob
At 15:53 25/08/2009, toby.moncaster at bt.com wrote:
This potentially raises an issue for all future PCN documents since
the
abstract was based on our agreed standard elevator-pitch
introduction to
PCN... Specifically Spencer raises the question of using the defined
term PCN-domain in the abstract. Any thoughts from anyone as to
whether
this is confusing? Would it be clearer to just use "domain" (e.g.
drop
the "PCN-"). In which case should I alter the whole abstract as
follows
(note: I realise this is strictly incorrect as it now doesn't seek
to
distinguish the non-PCN and PCN traffic from each other but is this
clearer for a casual reader?):
The objective of Pre-Congestion Notification (PCN) is to protect
the
quality of service (QoS) of inelastic flows within a Diffserv
domain.
The overall rate of the traffic is metered on every link in the
domain, and packets are appropriately marked when certain
configured rates are exceeded. Boundary nodes can measure the
level
of marking and thus make decisions about whether to admit or
block a
new flow request, and (in abnormal circumstances) whether to
terminate some of the existing flows, thereby protecting the QoS
of
previously admitted flows. This document specifies how such
marks
are encoded into the IP header by re-using the Explicit
Congestion
Notification (ECN) codepoints within this controlled domain. The
baseline encoding described here provides for only two PCN
encoding
states, Not-marked and PCN-marked.
Toby
-----Original Message-----
From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf
Of
Lars Eggert
Sent: 25 August 2009 15:12
To: pcn at ietf.org
Subject: [PCN] Fwd: [Gen-art] Gen-ART Review
ofdraft-ietf-pcn-baseline-
encoding-05
Begin forwarded message:
From: Spencer Dawkins <spencer at wonderhamster.org>
Date: August 25, 2009 14:47:49 GMT+02:00
To: "draft-ietf-pcn-baseline-encoding at tools.ietf.org"
<draft-ietf-
pcn-baseline-encoding at tools.ietf.org
Cc: General Area Review Team <gen-art at ietf.org>,
"ietf at ietf.org
" <ietf at ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-
encoding-05
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
Document: draft-ietf-pcn-baseline-encoding-05
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-09-03
Review Date: 2009-08-21
IESG Telechat date: (not known)
Summary: this specification is almost ready for publication as a
Proposed Standard. I have one minor question below (flagged as
"Spencer (minor)"), along with some editorial suggestions to be
considered when this document is edited (either in the working
group
or by the RFC Editor).
Abstract
The objective of Pre-Congestion Notification (PCN) is to protect
the
quality of service (QoS) of inelastic flows within a Diffserv
domain.
Spencer (clarity): I'm not sure what the relationship between a
Diffserv domain and a PCN-domain is - this couuld be clearer,
especially in an Abstract. I note that RFC 5559 doesn't use the
term
PCN-domain in its Abstract ... I can guess, but I'm just guessing.
The overall rate of the PCN-traffic is metered on every link in
the
PCN-domain, and PCN-packets are appropriately marked when
certain
configured rates are exceeded. The level of marking allows the
boundary nodes to make decisions about whether to admit or block
a
new flow request, and (in abnormal circumstances) whether to
terminate some of the existing flows, thereby protecting the QoS
of
previously admitted flows. This document specifies how such
marks
are to be encoded into the IP header by re-using the Explicit
Congestion Notification (ECN) codepoints within this controlled
domain. The baseline encoding described here provides for only
two
PCN encoding states, Not-marked and PCN-marked.
4. Encoding two PCN States in IP
The following rules apply to all PCN traffic:
o PCN-traffic MUST be marked with a PCN-compatible Diffserv
Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be
chosen that are already defined for use with admission
controlled
traffic. Appendix A.1 gives guidance to implementiors on
suitable
Spencer (clarity): s/implementiors/implementers/?
DSCPs. Guidelines for mixing traffic-types within a PCN-
domain
are given in [I-D.ietf-pcn-marking-behaviour].
o Any packet that is not-PCN but which shares the same Diffserv
codepoint as PCN-enabled traffic MUST have the ECN field of
its
outermost IP header equal to 00.
Spencer (minor): this is the only point in the specification (that
I
can
find) that makes reference to the "outermost IP header". I'm not
sure
whether to suggest s/outermost// here or to ask that a statement
be
added earlier in the document to clearly state that PCN encoding
only
protects inelastic traffic when it's used for the outermost IP
header,
but the current text seems to call attention to this in a way that
makes the reader wonder what is special about THIS requirement
that
isn't true of the other requirements listed.
4.3. PCN-Compatible Diffserv Codepoints
Enabling PCN marking behaviour for a specific DSCP disables any
other
marking behaviour (e.g. enabling PCN disables the default ECN
marking
behaviour introduced in [RFC3168]). All traffic metering and
marking
Spencer (clarity): here, and in Section 6, the text uses
"disables"
to
describe the relationship between PCN and ECN. If I understand the
point, the domain is substituting one behavior for another. I
might
suggest "replaces" to describe the relationship in both locations.
behaviours are discussed in [I-D.ietf-pcn-marking-behaviour].
This
ensures compliance with the BCP guidance set out in [RFC4774].
4.3.1. Co-existence of PCN and not-PCN traffic
The scarcity of pool 1 DSCPs coupled with the fact that PCN is
envisaged as a marking behaviour that could be applied to a
number
of
different DSCPs makes it essential that we provide a not-PCN
state.
As stated above (and expanded in Appendix A.1) the aim is for
PCN
to
re-use existing DSCPs. Because PCN re-defines the meaning of
the
ECN
Spencer (clarity): here, the text uses "re-defines", which I like
better than "disables", but if you go for "replaces" previously
and
in
section 6, you might want to use the same wording here.
field for such DSCPs it is important to allow an operator to
still
use the DSCP for traffic that isn't PCN-enabled. This is
achieved
by
providing a not-PCN state within the encoding scheme.
A.1. Choice of Suitable DSCPs
The PCN Working Group chose not to define a single DSCP for use
with
PCN for several reasons. Firstly the PCN mechanism is
applicable
to
a variety of different traffic classes. Secondly standards
track
DSCPs are in increasingly short supply. Thirdly PCN should be
seen
as being essentially a marking behaviour similar to ECN but
intended
for inelastic traffic. The choice of which DSCP is most
suitable
for
a given PCN-domain is dependent 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]. To be clear the PCN Working Group recommends
using
Spencer (clarity): is this 2119 language (apparently not, since
this
section is not normative), or are you saying "suggests"? My
suggestion
is that we not use 2119 language, even lowercased, except for
normative text - this seems to cause confusion from time to time.
But
please check with your shepherding AD to see if he agrees.
admission control for the following service classes:
o Telephony (EF)
o Real-time interactive (CS4)
o Broadcast Video (CS3)
o Multimedia Conferencing (AF4)
_______________________________________________
Gen-art mailing list
Gen-art at ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
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