Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

From: Tina TSOU <[email-masked]>
Date: Mon, 02 Jul 2007 11:38:25 +0800

Hi all,
One of the scenarios I am suggesting is below.

Even in Pull mode, application layer QoS request (via RSVP) should be also
sent from ingress to the centralized node, in centralized node the policy is
generated, then the decision is made, and then delivers to the Ingress to
enforce. I was not saying that the policy is directly generated in the
Ingress. Even the rather that Push mode should be also taken into account.

I.e. we define the centralized node locates in the transport control layer;
the Ingress and Egress locate in transport layer. For the implementation of
physical entities, they are service policy server and PCN-enabled router
respectively.

The centralized node is policy decision node, it should be based on (1)
Egress measurement result (2) operator's policies (could be configured in
the centralized node) (3) QoS request coming from the application layer
(PUSH or PULL mode), to make the decision, and decide which flows should be
admitted or reject, which flows should be stopped temperately or downgraded,
which flows should be done policing. The generated policy should be sent to
ingress for enforcement.

Ingress is the policy enforcement point, it based on the policy delivered by
the centralized node, (1) it allows flow pass or filter flow, (2) for the
flows allowed to pass, it makes policing and coloring based on the policy.

Referrence:
QoS "Push" Model: model where the centralised node "pushes" traffic policies 
to the transport functions to enforce its policy decisions.
NOTE: In this model, the CPE does not itself support native application 
independent QoS procedures.
QoS "Pull" Model: model where, upon request from the transport processing 
functions, the centralised node provides traffic policies to the transport 
processing functions. The request from the transport processing functions 
may itself, for example, be triggered by path-coupled requests coming from 
user equipment and/or transport network elements.

B. R.
Tina

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 28, 2007 11:59 PM
Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

Hi all,

Just a reminder that all comments on this draft would be great. It aims
to describe the PCN architecture, in light of the PCN WG's Charter & its
Milestone of an Info doc on 'Flow Admission and Termination Architecture
within a Diffserv Domain' (due Nov 07).

S1 Introduction.
This is quite short. If desired, it could be boosted with a general
explanation of where PCN fits into the picture of QoS and how it's
evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01)

S2 Terminology
In the "Editor's note" are 3 alternative terms that some of the authors
preferred.

S3 Assumptions and constraints on scope
These are the 4 things mentioned in the Charter, plus some explanation
of them. Are they clear? Also we mention some of the ways that a future
revised Charter might look at overcoming some of the
constraints/assumptions; is this sub-section at the right depth?

S4 High-level functional architecture
We have tried to write this section (and the following ones) so that it
fits all the various proposals there've been for PCN mechanisms. Does
this make the section too wishy-washy or too hard to understand? Should
it include some comparison of the different mechanisms proposed
(PCN-interior-node marking algorithms & PCN-boundary-node reactions)?

S5 Detailed Functional architecture
Is this a reasonable description of the extra functionality that PCN
requires on various nodes in the PCN-domain? Is it the right way to
split up the description? For clarity / help reader's understanding,
should there be some specific examples of how functionality might be
distributed (eg "if you followed the deployment model in
draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at
the PCN-egress-node, communicated to the PCN-ingress-nodes which makes
the admission decision; etc.")

S6 Design goals and challenges
This briefly describes some open issues, taken from
briscoe-tsvwg-cl-architecture. Are there other ones that should be
mentioned? Is the problem description at the right level of depth?
Should we discuss various possible solutions to these problems?

S7 Deployment scenarios
Briefly describes some deployment scenarios for pcn? is this at the
right level of depth?

S8 Operations and Management
This section was written in response to the Charter saying that the
architecture document should include security, manageability and
operational considerations. The draft addresses this by providing some
thoughts under the FCAPS headings: OAM of Faults, Configuration,
Accounting, Performance and Security? Is this the right way of
structuring it - does it cover the right set of topics? Is the text at
the right level? - eg should it also have a detailed set of parameters
that would be available for configuration?

An overall question is whether the draft should have more comparison of
the options (pros/cons) for various aspects.

I aim to edit another version of the draft before the ietf (but maybe
not before the deadline as I'm on hols next week).

Thanks!
Phil/

> -----Original Message-----
> From: Kwok-Ho Chan [mailto:[email-masked]]
> Sent: 22 June 2007 04:38
> To: [email-masked]
> Subject: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt
>
> Hi all:
> Please see the attached E-Mail on the posting of the PCN Architecture
> draft.
> On behave of the editor of this draft: Phil, and the co-authors of
this
> draft,
> we would like to request for reviews and comments of this draft and
> welcome
> any comments for improvements.
>
> Please send your comments/discussions of this draft on the PCN list.
>
> Thank you for your interest and review of this draft!
> -- Kwok on behave of the co-authors of this draft --
>
>
> >To: [email-masked]
> >Cc:
> >From: [email-masked]
> >Date: Thu, 21 Jun 2007 15:50:02 -0400
> >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
> >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt
> >X-BeenThere: [email-masked]
> >X-Mailman-Version: 2.1.5
> >Reply-To: [email-masked]
> >List-Id: i-d-announce.ietf.org
> >List-Unsubscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
> >  <mailto:[email-masked]?subject=unsubscribe>
> >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
> >List-Post: <mailto:[email-masked]>
> >List-Help: <mailto:[email-masked]?subject=help>
> >List-Subscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
> >  <mailto:[email-masked]?subject=subscribe>
> >X-Spam-Tests: FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106,
> >  NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1,URIBL_MANURI=4
> >X-Spam-Score: 5.3
> >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on
> ecarhea1.nortel.com
> >X-DNSBL-Score: -50
> >X-DNSBL-Servers: bl.nortel.com
> >X-SMTP-HELO: megatron.ietf.org
> >X-SMTP-MAIL-FROM: [email-masked]
> >X-SMTP-RCPT-TO:
>
>[email-masked],[email-masked],[email-masked],bharrath@nortel
.c
om,[email-masked],[email-masked],[email-masked],simmonds@nortel
.c
om,[email-masked],[email-masked],[email-masked],[email-masked]
om
> >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145]
> >X-SMTP-REASON: PASSED
> >X-SMTP-ID: 1182455563.14011407
> >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC)
> >FILETIME=[BC4965C0:01C7B43D]
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> >         Title           : Pre-Congestion Notification Architecture
> >         Author(s)       : P. Eardley, et al.
> >         Filename        : draft-eardley-pcn-architecture-00.txt
> >         Pages           : 27
> >         Date            : 2007-6-21
> >
> >    The purpose of this document is to describe a general
architecture
> >    for flow admission and termination based on aggregated (pre-)
> >    congestion information in order to protect the quality of service
of
> >    established inelastic flows within a single DiffServ domain.
> >
> >
> >A URL for this Internet-Draft is:
>
>http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00.t
xt
> >
> >To remove yourself from the I-D Announcement list, send a message to
> >[email-masked] with the word unsubscribe in the body
of
> >the message.
> >You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> >to change your subscription settings.
> >
> >Internet-Drafts are also available by anonymous FTP. Login with the
> >username "anonymous" and a password of your e-mail address. After
> >logging in, type "cd internet-drafts" and then
> >"get draft-eardley-pcn-architecture-00.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         [email-masked].
> >In the body type:
> >         "FILE
/internet-drafts/draft-eardley-pcn-architecture-00.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the
"FILE"
> >         command.  To decode the response(s), you will need "munpack"
or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been
split
> >         up into multiple messages), so check your local
documentation on
> >         how to manipulate these messages.
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
> >
> >Content-Type: text/plain
> >Content-ID: <[email-masked]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-eardley-pcn-architecture-
> 00.txt>
> >_______________________________________________
> >I-D-Announce mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
>
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pcn

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 2 Jul 2007 08:16:43 +0200

Hello Tina,

|Even in Pull mode, application layer QoS request (via RSVP) 
|should be also sent from ingress to the centralized node, in centralized node 
|the policy is generated, then the decision is made, and then delivers to the 
|Ingress to enforce. I was not saying that the policy is directly generated in the
|Ingress. Even the rather that Push mode should be also taken 
|into account.

Do you have any specific protocol in mind for this purpose (e.g. COPS) or 
is your aim to look for agreement at this stage and to worry about 
interfaces and protocols later on?

Regards, Ruediger

[snipped the rest, as no further comment from my side]

---

From: Tina TSOU <[email-masked]>
Date: Tue, 03 Jul 2007 09:58:16 +0800

Hi Ruediger,
Thanks for your comments:)
See comment in line.

B. R.
Tina

----- Original Message ----- 
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 02, 2007 2:16 PM
Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

Hello Tina,

|Even in Pull mode, application layer QoS request (via RSVP)
|should be also sent from ingress to the centralized node, in centralized
node
|the policy is generated, then the decision is made, and then delivers to
the
|Ingress to enforce. I was not saying that the policy is directly generated
in the
|Ingress. Even the rather that Push mode should be also taken
|into account.

Do you have any specific protocol in mind for this purpose (e.g. COPS) or
is your aim to look for agreement at this stage and to worry about
interfaces and protocols later on?
[Tina: I don't have specific protocol in mind. It could be COPS, H.248,
Diameter etc.
I don't worry about the interfaces and protocols later on.
I just highlighted that this typical scenario is not explicitly include in
the arch-00 draft yet.
And this scenario makes impact on the functionalities of the entities in PCN 
arch.]

Regards, Ruediger

---

From: Michael Menth <[email-masked]>
Date: Wed, 04 Jul 2007 09:06:15 +0200

Hi Phil et al.,

after another reading of the PCN architecture draft
http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00.txt
here are some comments.

1. Intro:

   o  The configured-admissible-rates can be chosen small enough that 
admitted traffic can still be carried after a rerouting in most failure 
cases.  This is an important feature as QoS violations in core networks 
due to link failures are more likely than QoS violations due to 
increased traffic volume.

appropriate citation:
http://www.ieee-infocom.org/2003/papers/10_04.PDF

some history: see Section III of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-Config.pdf

2. Terminology:

I would like to have discussed also the nomenclature in the Three State 
PCN Marking draft:
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt

3. Assumptions:

Should headlines be uppercase or lowercase (cf. 3., 3.1, 3.2, ...)?

Is only a single PCN in the scope of the current charter or several PCN 
classes with different scheduling priority? We had some discussion on 
this earlier. This issue also relates to the bullet list at the end of 
Section 4.

4.  High-level functional architecture

I think it makes sense to define the term "pre-congestion": a link with 
capacity C is pre-congested with regard to a rate threshold R<C if its 
current traffic rate is above R. This applies both to the 
configurable-admission-rate and configurable-termination-rate 
thresholds, i.e., there are different types of pre-congestion. We 
introduced this notion in Section 2 of  the "Three State PCN Marking" draft:
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt

5.  Detailed Functional architecture

Comment to probing: probe packets need to have the same header as data 
packet, otherwise might be transported over different paths when ECMP is 
on and flow-based load distribution is based on hash values of the 
packet headers. Then, my next question is: how does the PCN egress node 
recognize a probe packet as a such? I think that this is a fundamental 
problem which requires a standardized solution that is essential to a 
signalling draft. Therefore, it might be worth mentioning.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 4 Jul 2007 09:14:14 -0400

>this earlier. This issue also relates to the bullet list at the end of 

[Joe]I believe that PCN architecture should assume that there may be one
or more PCN classes in a domain. The architecture states that Diffserv
is used in the domain so multiple service classes are possible and the
PCN mechanism may be applied to one or more service classes that support
real-time inelastic traffic.  

>signalling draft. Therefore, it might be worth mentioning.

[Joe]I think we need to identify methods where the interior nodes from
routing perspective can threat probe packets as PCN data but egress node
can easily identify them as probe packets. I also believe that the probe
concept could be used to convey ingress node's address to the egress
node so that egress knows which ingress node to send PCN pre-congestion
information.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: July 4, 2007 3:06 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

Hi Phil et al.,

after another reading of the PCN architecture draft
http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00.tx
t
here are some comments.

1. Intro:

appropriate citation:

some history: see Section III of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-
Config.pdf

2. Terminology:

3. Assumptions:

introduced this notion in Section 2 of  the "Three State PCN Marking"
draft:

Regards,

    Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 4 Jul 2007 16:19:00 +0200

Hi Joe, Hi Michael

Please see in line!

> From: Jozef Babiarz [mailto:[email-masked]] 
> Sent: woensdag 4 juli 2007 15:14
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] Fwd: I-D 
> ACTION:draft-eardley-pcn-architecture-00.txt
> 
> Michael wrote:
> >3. Assumptions:
> >
> [Joe]I believe that PCN architecture should assume that there 
> may be one or more PCN classes in a domain. The architecture 
> states that Diffserv is used in the domain so multiple 
> service classes are possible and the PCN mechanism may be 
> applied to one or more service classes that support real-time 
> inelastic traffic.  

[Georgios] I think that it has not been decided yet, 
whether the PCN architecture should assume that there might 
be one or more PCN classes in a domain. 

> [Joe]I think we need to identify methods where the interior 
> nodes from routing perspective can threat probe packets as 
> PCN data but egress node can easily identify them as probe 
> packets. I also believe that the probe concept could be used 
> to convey ingress node's address to the egress node so that 
> egress knows which ingress node to send PCN pre-congestion 
> information.

[Georgios] I agree with Joe's proposal that an PCN interior node 
should treat probe packets as PCN data but the PCN egress node 
should easily identify them as probe packets.

Best regards,
Georgios

> Subject: Re: [PCN] Fwd: I-D 
> ACTION:draft-eardley-pcn-architecture-00.txt
> 
> Hi Phil et al.,
> 
>    o  The configured-admissible-rates can be chosen small 
> enough that admitted traffic can still be carried after a 
> rerouting in most failure cases.  This is an important 
> feature as QoS violations in core networks due to link 
> failures are more likely than QoS violations due to increased 
> traffic volume.
> 
> appropriate citation:
> I would like to have discussed also the nomenclature in the 
> Three State PCN Marking draft:
> Is only a single PCN in the scope of the current charter or 
> several PCN classes with different scheduling priority? We 
> had some discussion on this earlier. This issue also relates 
> to the bullet list at the end of Section 4.
> 
> 
> I think it makes sense to define the term "pre-congestion": a 
> link with capacity C is pre-congested with regard to a rate 
> threshold R<C if its current traffic rate is above R. This 
> applies both to the configurable-admission-rate and 
> configurable-termination-rate thresholds, i.e., there are 
> different types of pre-congestion. We introduced this notion 
> in Section 2 of  the "Three State PCN Marking"
> draft:
> Comment to probing: probe packets need to have the same 
> header as data packet, otherwise might be transported over 
> different paths when ECMP is
> 
> on and flow-based load distribution is based on hash values 
> of the packet headers. Then, my next question is: how does 
> the PCN egress node recognize a probe packet as a such? I 
> think that this is a fundamental problem which requires a 
> standardized solution that is essential to a signalling 
> draft. Therefore, it might be worth mentioning.
> 
> Regards,
> 
>     Michael
> 
> > S3 Assumptions and constraints on scope These are the 4 things 
> > mentioned in the Charter, plus some explanation of them. Are they 
> > clear? Also we mention some of the ways that a
> future
> > draft-briscoe-tsvwg-cl-architecture-04, then this 
> measurement is made
> at
> >> Subject: [PCN] Fwd: I-D 
> ACTION:draft-eardley-pcn-architecture-00.txt
> >>
> >> Hi all:
> >> welcome any comments for improvements.
> >>
> >>> logging in, type "cd internet-drafts" and then "get 
> >>> draft-eardley-pcn-architecture-00.txt".
> >>>
> >>> http://www.ietf.org/shadow.html or 
> >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: Lars Eggert <[email-masked]>
Date: Wed, 4 Jul 2007 18:29:07 +0300

Hi,

I briefly read over this document. I think it generally goes into the  
right direction and is very complete for a -00 draft - nice job.

I do have some comments, however:

Section 1., paragraph 2:
 >    Each link of the PCN-
 >    domain can be associated with a configured-admissible-rate and a
 >    configured-termination-rate.  If PCN-traffic, that is traffic  
in the
 >    DiffServ class(es) subject to the PCN mechanisms, on the link  
exceeds
 >    these rates then PCN-packets are admission-marked or termination-
 >    marked.

   This paragraph and the related text in the remainder of the document
   imply some particular technical directions: (1) marking is done based
   on pre-configured rates, rather than, for example, queue dynamics,  
and
   (2) there are two kinds of explicit markings (admission/termination),
   rather than, for example, basing the admission/termination  
decision on
   the arrival dynamic changes of a single marking over a sampling
   interval. Was this a deliberate choice of the authors?

Section 2., paragraph 0:
 > 2.  Terminology

   I'd be good to reuse or extend the definitions in RFC2475.

Section 4., paragraph 1:
 >    After completion of the initial phase, the PCN WG may re- 
charter to
 >    consider applying the PCN mechanisms to additional deployment
 >    scenarios (operation over concatenated DiffServ domains, PCN-aware
 >    application mechanisms, etc.).  The WG may also re-charter to  
develop
 >    solutions for scenarios where some of these restrictions are  
not in
 >    place.  For example, the WG might consider other response  
mechanisms
 >    that act on (pre-)congestion information, for example flow-rate
 >    adaptation by elastic applications (rather than flow admission or
 >    termination); and the WG might consider operating PCN over
 >    concatenated PCN-domains that don't trust each other, using re- 
ECN,
 >    I-D.briscoe-tsvwg-re-ecn-border-cheat [8] or similar  
techniques.  The
 >    details of these work items are outside the scope of the initial
 >    phase, but the WG may consider their requirements in order to  
design
 >    components that are sufficiently general to support such  
extensions
 >    in the future - the working assumption is that the standards
 >    developed in the initial phase should not need to be modified to
 >    satisfy the solutions for when these restrictions are removed.

   The architecture document is not the place to discuss what the WG may
   do in the future, especially because the text above subtly differs
   from the charter. Suggest to cut this part.

Section 4., paragraph 3:
 >    o  PCN-boundary-nodes at the edge of the PCN-domain, which control
 >       admission of new PCN-flows and termination of existing PCN- 
flows,
 >       based on information from PCN-interior-node.  This  
information is
 >       in the form of the PCN-marked data packets and not signalling
 >       messages.  PCN-ingress-nodes are flow-aware (required for  
policing
 >       purposes) In several deployment scenarios PCN-egress-nodes will
 >       also be flow aware.  For example I-D.briscoe-tsvwg-cl- 
architecture
 >       [2]describes a deployment scenario where RSVP messages are
 >       processed at both the PCN-ingress-node and PCN-egress-node (but
 >       not at any PCN-interior-nodes), and both store associated  
per flow
 >       state.

   If "some deployment scenarios" that the architecture is supposed to
   support require per flow-state on other nodes that the
   PCN-ingress-nodes, then that means that the architecture as a whole
   must support that. Because ingress nodes will usually also be egress
   nodes, and vice versa, that isn't actually a large change, but making
   this explicit is good IMO.

Section 4., paragraph 12:
 >    At a high level, flow termination control works as follows.  Each
 >    PCN-node termination-marks PCN-packets in a similar fashion to  
above.
 >    An obvious approach is for the algorithm to use instead a  
configured-
 >    termination-rate (which is higher than the configured-admissible-
 >    rate) and the encoding to use another packet marking; however  
there
 >    is also a proposal to use the same configured-admissible-rate  
and the
 >    same encoding.  Several approaches have been proposed to date  
about
 >    how to convert this information into a flow termination  
decision; at
 >    a high level these are as follows:

   OK, this makes it clear that the details of the marking aren't fixed
   yet (see my first comment.) Suggest to rephrase the text that
   talks about two types of markings through the document.

Section 4., paragraph 20:
 >    but for example I-D.lefaucheur-rsvp-ecn [9]describes the  
extensions
 >    needed for RSVP.

   draft-lefaucheur-rsvp-ecn doesn't exist in the tracker?

Section 4., paragraph 21:
 >    The following are some high-level points about how PCN works:
 >
 >    o  There needs to be a way for a PCN-node to distinguish PCN- 
traffic
 >       from non PCN-traffic.  This is based on the DSCP field and/ 
or ECN
 >       field.  The PCN mechanisms may be applied to more than one  
traffic
 >       class (which are distinguished by DSCP).
 >
 >    o  There may be traffic that is more important than PCN, perhaps a
 >       particular application or an operator's control messages.  A  
PCN-
 >       node may dedicate capacity to such traffic or priority  
schedule it
 >       over PCN.  In the latter case its traffic needs to  
contribute to
 >       the PCN meters.
 >
 >    o  There will be traffic less important than PCN.  For instance  
best
 >       effort or assured forwarding traffic (assuming PCN is being
 >       applied to the Expedited forwarding class).  It will be  
scheduled
 >       at lower priority than PCN, and use a separate queue or queues.
 >       However, a PCN-node may dedicate some capacity to lower  
priority
 >       traffic so that it isn't starved.
 >
 >    o  There may be other traffic with the same priority as PCN- 
traffic.
 >       For instance, Expedited Forwarding sessions that are originated
 >       either without capacity admission or with traffic  
engineering, and
 >       EF sessions that are originated using PCN admission  
control.  In
 >       I-D.ietf-tsvwg-admitted-realtime-dscp [5] the two traffic  
classes
 >       are called EF and EF-ADMIT.  A PCN-node could either use  
separate
 >       queues, or separate policers and a common queue; the draft
 >       provides some guidance when each is better, but for instance  
the
 >       latter is preferred when the two traffic classes are  
carrying the
 >       same type of application with the same jitter requirements.

   Wasn't the consensus after the BOF that the assumption is that all
   traffic in a PCN domain is PCN traffic? Because otherwise best-effort
   traffic can gobble up capacity that becomes available after a
   termination decision, etc. I'm surprised to see that there is now
   other traffic sharing the PCN domain.

 > 5.  Detailed Functional architecture

   I'm holding off commenting on section 5 until we've discussed the
   comments I making now. (Because section 5 is a different view on the
   same problem, many of the comments made for the other sections apply
   there as well.)

Section 6., paragraph 2:
 >    I-D.chan-pcn-problem-statement [10] considers the following as key
 >    design goals, ie why PCN is interesting:

   The requirements of [10] are not in line with the charter anymore.

Section 6., paragraph 4:
 >    o  Compatibility with other traffic (i.e. a proposed solution  
should
 >       work well when non-PCN traffic is also present in the network)

   BOF consensus was to declare this out-of-scope.

Section 7., paragraph 0:
 >  7.  Deployment scenarios

   Please clearly mark which of these scenarios are outside the scope of
   the initial charter. I'm OK with giving them as examples of what PCN
   ideally/eventually could support, but the focus should be on  
scenarios
   that can be realized under the initial charter.

Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 5 Jul 2007 10:40:59 +0200

Hi Lars,

my remarks in line.

Regards, Ruediger.

Section 1., paragraph 2:
> configured-termination-rate.  If PCN-traffic, that is traffic in the
> DiffServ class(es) subject to the PCN mechanisms, on the link exceeds

 This paragraph and the related text in the remainder of the document
 imply some particular technical directions: (1) marking is done based
 on pre-configured rates, rather than, for example, queue dynamics, and
 (2) there are two kinds of explicit markings (admission/termination),
 rather than, for example, basing the admission/termination decision on
 the arrival dynamic changes of a single marking over a sampling
 interval. Was this a deliberate choice of the authors?

[RG] (1) I'm no expert on the mechanisms, but I prefer settable rates 
to allow traffic engineering. As far as I know rate limited queues are
one 
solution option.

[RG] (2) There's no decision yet on the marking mechanism. Claryfying 
the marking options and the possible interpretations of the markings is
a 
reasonable aim.

[RG] That has been partially done, but I'll extend that to all terms.

Section 4., paragraph 1:
> After completion of the initial phase, the PCN WG may re-charter to
> application mechanisms, etc.).  The WG may also re-charter to develop
> solutions for scenarios where some of these restrictions are not in
> place.  For example, the WG might consider other response mechanisms
> concatenated PCN-domains that don't trust each other, using re-ECN,
> I-D.briscoe-tsvwg-re-ecn-border-cheat [8] or similar techniques.  The
> phase, but the WG may consider their requirements in order to design
> components that are sufficiently general to support such extensions

[RG] Could the architecture repeat the "out of scope declarations"  
of the charter?

Section 4., paragraph 3:
> o  PCN-boundary-nodes at the edge of the PCN-domain, which 
>    admission of new PCN-flows and termination of existing PCN-flows,
>    based on information from PCN-interior-node.  This information is
>    messages.  PCN-ingress-nodes are flow-aware (required for policing
>    also be flow aware.  For example I-D.briscoe-tsvwg-cl-architecture
>    not at any PCN-interior-nodes), and both store associated per flow
>    state.

[RG] I agree.

Section 4., paragraph 12:
> PCN-node termination-marks PCN-packets in a similar fashion to above.
> An obvious approach is for the algorithm to use instead a configured-
> rate) and the encoding to use another packet marking; however there
> is also a proposal to use the same configured-admissible-rate and the
> same encoding.  Several approaches have been proposed to date about
> how to convert this information into a flow termination decision; at

Section 4., paragraph 20:
> but for example I-D.lefaucheur-rsvp-ecn [9]describes the extensions
> needed for RSVP.

Section 4., paragraph 21:
> o  There needs to be a way for a PCN-node to distinguish PCN-traffic
>    from non PCN-traffic.  This is based on the DSCP field and/or ECN
>    field.  The PCN mechanisms may be applied to more than one traffic
>    particular application or an operator's control messages.  A PCN-
>    node may dedicate capacity to such traffic or priority schedule it
>    over PCN.  In the latter case its traffic needs to contribute to
>    the PCN meters.
>
> o  There will be traffic less important than PCN.  For instance best
>    applied to the Expedited forwarding class).  It will be scheduled
>    However, a PCN-node may dedicate some capacity to lower priority
> o  There may be other traffic with the same priority as PCN-traffic.
>    either without capacity admission or with traffic engineering, and
>    EF sessions that are originated using PCN admission control.  In
>    I-D.ietf-tsvwg-admitted-realtime-dscp [5] the two traffic classes
>    are called EF and EF-ADMIT.  A PCN-node could either use separate
>    provides some guidance when each is better, but for instance the
>    latter is preferred when the two traffic classes are carrying the

[RG] I don't think that the only traffic within a PCN domain is PCN 
traffic. Best Effort traffic should be present due to economic reasons. 
Let's say provisioning and engineering result in PCN traffic to be 
transported free of losses also after a single link loss, then 
approxinately 50% of the network capacity aren't used for PCN under 
normal conditions. The remaining 50% could and should e.g. be used 
for Best Effort.
DiffServ is deployed within commercial backbones, so I think it is 
also reasonable to expect other DiffServ classes to be present. 
Extending this argument to "DiffServ is also operated to transport 
inealastic real time traffic", you end up in a situation, where 
PCN even can't claim  a dedicated queue. Migration to PCN probably 
requires to deal with non PCN traffic sharing the same queue. 
That's not nice, but that's how it is.

[RG] Only if you build a real time transport plattform from scratch or 
as you describe, a separate network, then a PCN domain will be 
completely isolated.

Section 6., paragraph 4:
> o  Compatibility with other traffic (i.e. a proposed solution should

[RG] I'm sorry, but when did the BOF or the mailing list discuss or 
decide this?

 Please clearly mark which of these scenarios are outside the scope of
 the initial charter. I'm OK with giving them as examples of what PCN
 ideally/eventually could support, but the focus should be on scenarios
 that can be realized under the initial charter.

[RG] I agree. Setting up a separate list or having two sub chapters 
"within scope" and "out of scope" may be reasonable.

---

From: Steven Blake <[email-masked]>
Date: Thu, 05 Jul 2007 18:04:36 -0400

>    other traffic sharing the PCN domain.

I was not involved with the BOF, but by my reading of charter, I don't
see anything implying such a restriction; and it is certainly a whopper
of a restriction!  

Dedicating one (or more) DS behavior aggregate(s) for PCN-managed
traffic makes perfect sense, but assuming that either AF or EF PHBs are
used to service the PCN-managed BA, that BA will have a guaranteed
minimal service rate at each router link that will protect the BA
service from variations in best-effort traffic load.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 5 Jul 2007 22:19:56 -0400

in the
exceeds

 > on pre-configured rates, rather than, for example, queue dynamics,  
[Joe]Yes. The detection of PCN traffic level is done using some form of
a rate measurement or rate compression. PCN deals with inelastic traffic
and the rate measurement approach seams to work. I'm interpreting that
by queue dynamics you mean something like what is used in AQM? 

>   other traffic sharing the PCN domain.
[Joe]My understanding is that PCN is applied to a Diffserv domain and
one or more service classes may support the PCN mechanism. There maybe
service classes that do not support PCN, e.g., best-effort, etc. PCN is
only applied to inelastic traffic like voice and video.  

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: July 4, 2007 11:29 AM
To: [email-masked]
Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

Hi,

in the
exceeds

charter to
develop
not in
mechanisms
ECN,
techniques.  The
design
extensions

flows,
information is
policing
architecture
per flow

above.
configured-
there
and the
about
decision; at

extensions

traffic
or ECN
traffic
PCN-
schedule it
contribute to
best
scheduled
priority
traffic.
engineering, and
control.  In
classes
separate
the
carrying the

should

Lars

---

From: <[email-masked]>
Date: Mon, 9 Jul 2007 12:22:07 +0100

Michael - thanks!
In-line below
phil

> Sent: 04 July 2007 08:06
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Config.pdf

ok

> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt

let the discussion begin!

> this earlier. This issue also relates to the bullet list at the end of

My view is that both are possible. 

> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt

would this definition also catch ECN (which 3168 considers congestion,
rather than pre-congestion)?

> signalling draft. Therefore, it might be worth mentioning.

Including a discussion about this somewhere seems good. I don't think
we've properly discussed what the requirements on probing are. Eg I'm
not sure the egress node necessarily has to recognise a probe pkt - the
crucial thing is that enough traffic is generated on the
ingress-egress-aggregate to make the adm decision. 
Perhaps we should start a separate discussion about probing.

---

From: <[email-masked]>
Date: Mon, 9 Jul 2007 13:03:04 +0100

Lars, Ruediger
Thanks for the comments!
In-line below
phil

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 05 July 2007 09:41
> To: [email-masked]
> Cc: [email-masked]
exceeds
and
> the marking options and the possible interpretations of the markings
is

(1) I don't think 'everything but pre-configured rates' is excluded. I
think the algorithm will somehow involve a characteristic traffic rate.
I presume people who have other ideas about the algorithm should submit
a draft or comment on the existing suggestions. There is an open
question about how detailed the algorithm spec should be (what is an
implementation choice)

(2) 2 explicit encodings is not decided.

In general I think purely using arrival dynamics to distinguish between
adm & termination decision is hard - since you want to react fast to
problems (whether adm control or flow termination), but on the other
hand it will take some time for a flow termination decision to have an
impact on the marks seen at the egress.  

> [RG] That has been partially done, but I'll extend that to all terms.

Tried to do, obviously not that well. Maybe 2475 terminology experts can
advise?

develop
> [RG] Could the architecture repeat the "out of scope declarations"

Ok, will try again - wasn't trying to say anything different from
charter - but thought the draft should mention that the WG should keep
the inter-domain requirements (cf border-cheat) "strongly in mind" (I
think that was the phrase at the BoF).

policing
>  this explicit is good IMO.

Ok

above.
configured-
>  talks about two types of markings through the document.

Will try for some re-phrasing. 

>  draft-lefaucheur-rsvp-ecn doesn't exist in the tracker?

It has expired - is it ok still to reference it?

traffic
> as you describe, a separate network, then a PCN domain will be

I basically agree with Ruediger. Lars: yes, the BE gobbles up the
capacity that becomes available after a termination decision - however
it is in a different DS class at lower priority.

The bullets in the draft are my attempt to summarise the consensus view.

>  The requirements of [10] are not in line with the charter anymore.

Ok, I'll have a check.

scenarios
> "within scope" and "out of scope" may be reasonable.

Ok, will try & re-write.

---

From: <[email-masked]>
Date: Mon, 9 Jul 2007 13:16:00 +0100

Tina
Thanks
I'm not sure I completely understand your comments, sorry.

Is the problem that at the moment the draft only describes the Pull
model and not the Push model? Which lines of text need changing?
(somewhere in Section 5.4 or section 7 or somewhere else?)

Thanks!
phil

> From: Tina TSOU [mailto:[email-masked]]
> Sent: 02 July 2007 04:38
> To: [email-masked]; Eardley,PL,Philip,CXR9 R
> sent from ingress to the centralized node, in centralized node the
policy
> the Ingress and Egress locate in transport layer. For the
implementation
> (PUSH or PULL mode), to make the decision, and decide which flows
should
> be
> which flows should be done policing. The generated policy should be
sent
> to
> ingress for enforcement.
> 
> Ingress is the policy enforcement point, it based on the policy
delivered
> by

---

From: Tina TSOU <[email-masked]>
Date: Wed, 11 Jul 2007 11:55:43 +0800

Hi Phil,
I made some proposed specific changes with revised mark together with 
comments in the attachment.
Hope it helps:)

B. R.
Tina

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, July 09, 2007 8:16 PM
Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

Tina
Thanks

Thanks!
phil

policy
implementation
should
sent
delivered

---

From: Tom Taylor <[email-masked]>
Date: Wed, 11 Jul 2007 12:30:15 -0400

The idea of using a centralized node to collect the egress reports makes a lot 
of sense. We had the earlier discussion about how the egress node knows where to 
send its reports. If a centralized collection point is used, the address of that 
collection point can be configured in the egress nodes rather than requiring 
them to be topology-aware.

Of course, that pushes the problem back to the collection node, but the problem 
may be simpler there.

Tina TSOU wrote:
> ----- Original Message ----- From: <[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 12 Jul 2007 12:05:04 +0300

> service from variations in best-effort traffic load.

I checked the notes from the BOF, and apparently I was misremembering  
things. The topic of how to deal with non-PCN traffic was discussed  
and the idea was to address it through DiffServ classes. So please  
ignore those comments in my review of the architecture draft.

Lars

---

From: <[email-masked]>
Date: Thu, 12 Jul 2007 12:45:38 +0100

Tina

Thanks

Your changes in S1 & S2 seem good to me.

You made a comment in S5.4, but didn't suggest a text change. I think
your comment doesn't need any change to S4 (ie it's already covered
either in S5.4 [option of centralised node making decision] or earlier
[ingress node doing policing]. is that ok?

Thanks
Phil/ 

> Sent: 11 July 2007 04:56
> > Even in Pull mode, application layer QoS request (via RSVP) should
be
> also
> > generated, then the decision is made, and then delivers to the
Ingress
> > Egress measurement result (2) operator's policies (could be
configured
> in
> > the centralized node, (1) it allows flow pass or filter flow, (2)
for
> > may itself, for example, be triggered by path-coupled requests
coming
> from
> > draft-briscoe-tsvwg-cl-architecture-04, then this measurement is
made

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Jul 2007 16:39:47 +0800

Hi Phil,
Thanks:)

Wrt to section 5.4, I suggest as below.
/*delete "policy and"*/
/*add "and relative QoS policies"*/
The decision is made at a centralised node, which requires that
the PCN-egress-node signals to the centralised node about "the
required measurements of PCN-traffic" (and that the centralised
node learns about policy and application layer requirements), and
that the centralised node signals to the PCN-ingress-node about
the decision about admission control and relative QoS policies.  It would be 
possible for
the centralised node to be one of the PCN-boundary-nodes, when
clearly the signalling would sometimes be replaced by a message
internal to the node.

B. R.
Tina

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 12, 2007 7:45 PM
Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

Tina

Thanks

Thanks
Phil/

be
Ingress
configured
for
coming
made

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Jul 2007 17:27:17 +0800

Sorry, forgot to delete "policy and". They should be display as below.

> node learns about application layer requirements), and
> the decision about admission control and relative QoS policies.  It would 
> be possible for

B. R.
Tina

----- Original Message ----- 
From: "Tina TSOU" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, July 13, 2007 4:39 PM
Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

> the decision about admission control and relative QoS policies.  It would 
> be possible for

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 24 Jul 2007 01:15:23 +0100

Phil, Lars, Ruediger,

Dragging back one issue on a thread that ended a couple of weeks ago...

>question about how detailed the algorithm spec should be (what is an

I just wanted to point out that the configuration OAM section (8.2) of the 
arch draft (which I've now read) already says the configured-admissable 
rate need not actually be pre-configured.

It refers to [21] by Songhurst et al, which suggests an alternative way to 
do marking. I don't know whether this was the sort of stuff Lars was 
thinking of.

In Songhurst, the virtual queue does have a configured-rate, but the 
operator doesn't have to predict what proportion of each link to configure 
for PCN traffic. Instead, the virtual queue's drain rate is always set to 
(say) 99% of the line rate. But Songhurst's marking probability depends on 
the sum of the length of the PCN virtual queue plus the length(s) of the 
real lower priority queue(s) (e.g. BE).

So if there's not much BE, admission control allows more PCN traffic before 
it kicks in. But if there's a lot of BE, admission control kicks at a lower 
level of PCN.

IOW, the boundary between PCN & other traffic floats depending on their 
relative loads. Songhurst also describes how this floating can be bounded 
between high a low water marks, so there's min amounts of capacity for BE 
and a min for PCN (protecting PCN during BE DoS attacks). Basically, it's 
all about getting the best out of the network however good or bad the 
config is.

Two reasons for saying this to the list:
i) Is being less sensitive to accurate traffic matrix prediction something 
other operators would be interested in?
ii) The text needs correcting slightly, because it says Songhurst's method 
doesn't use a pre-configured rate, but it does - it just doesn't have to be 
accurate.

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 24 Jul 2007 10:16:33 +0200

Bob,

|Two reasons for saying this to the list:
|i) Is being less sensitive to accurate traffic matrix 
|   prediction something other operators would be 
|   interested in?
|ii) The text needs correcting slightly, because it says 
|    Songhurst's method doesn't use a pre-configured 
|    rate, but it does - it just doesn't have to be 
|    accurate.

My argumentation on settable rates came from experience 
with the Priority Promotion Scheme (PPS, a measurement 
based admission control scheme), which didn't 
foresee settable rates and I couldn't convince the 
authors to introduce them. 

I don't object to your proposal allowing for less accurate 
prediction of the traffic matrix. Whatever the resolution 
is, other PHBs may have to be protected from a capacity 
breathing PCN class. But that could be done by making sure 
that PCN traffic shares links with best effort background 
traffic only too (and just ensuring a minimum capacity 
for best effort).

Regards,

Ruediger

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 24 Jul 2007 19:02:29 +0100

Ruediger,

>traffic only too (and just ensuring a minimum capacity

I agree totally with you that most operators currently prefer to nail up 
capacaity for each class (usually with borrowing from 'lower' into 
'upper'). This fits the current business models and ways that SLAs are written.

I just didn't want the PCN architecture to constrain all operators to _not_ 
have breathing within limits and _only_ have hard limits. Otherwise we are 
preventing potential new, more flexible business models developing, wihch 
the IETF should avoid. As long as we can allow this flexibility by avoiding 
the wording being unnecessarily constraining, I don't think anyone need 
object, as long as it doesn't make any initial PCN implementations more 
complex.

Cheers

Bob