-----Original Message-----
From: Bob Briscoe [mailto:bob at homefarmparham.co.uk]
Sent: 26 August 2009 17:15
To: Moncaster,T,Toby,DER3 R
Subject: Fwd: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
baseline-encoding-05
Toby,
inline, following up my own post...
Date: Wed, 26 Aug 2009 16:50:15 +0100
To: menth at informatik.uni-wuerzburg.de, Ruediger.Geib at telekom.de
From: Bob Briscoe <bob at homefarmparham.co.uk>
Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART
Review ofdraft-ietf-pcn-baseline-encoding-05
Cc: toby.moncaster at bt.com, pcn at ietf.org
Michael,
I agree that we should use the term PCN to mean
the notification part, not the whole traffic
control system built around it. We had this
discussion when publishing the architecture.
* CORRECT: what Phil did in the Intro to the architecture.
"
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv
domain
in a simple, scalable, and robust fashion.
"
(paraphrasing: the *objective* of notification is to protect QoS)
* INCORRECT: The first sentence of Toby's abstract says:
"Pre-Congestion Notification (PCN) is a metering and marking scheme
that
protects the quality of service (QoS) of
inelastic flows within a Diffserv
domain."
(paraphrasing: notification *is* a scheme that protects QoS)
Suggestion to fix the first
sentence:"Pre-Congestion Notification (PCN) is a
scheme for metering and marking packets that
can be used to protect the quality of service
(QoS) of inelastic flows within a Diffserv domain."
Just realised that's ambiguous: "scheme that can
be used" or "packets that can be used"?
2nd attempt:
"Pre-Congestion Notification (PCN) is a scheme
for packet metering and marking that can be used
to protect the quality of service (QoS) of
inelastic flows within a Diffserv domain."
Bob
At 16:12 26/08/2009, Michael Menth wrote:
Hi Ruediger, Toby,
Ruediger.Geib at telekom.de schrieb:
Toby,
you simply ommited some "PCN" in your new
version. I think the problem addressed by
Spencer may be that you try to sum up RFC5559 rather then refer to
it.
Below there's an abstract proposal, structured top-down:
- What's PCN: a copy of the abstract of RFC5559.
- What's the functionality relevant for this document: marking
- What's specified by this document: baseline encoding
My try:
PCN specifies flow admission and termination
based on pre-congestion information in order
to protect the quality of service of
established, inelastic flows within a single Diffserv domain.
What is PCN? Or is admission control and flow
termination also part of PCN? My take on this
is that PCN is only the marking scheme and the
way the information is carried to egress nodes.
AC and FT is just built on top of PCN. And to
support QoS is the objective of AC and FT, not
primarily or only indirectly the objective of the marking scheme.
Regards,
Michael
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
--
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