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

From: <[email-masked]>
Date: Tue, 7 Aug 2007 14:09:05 +0100

Tina

delayed follow-up (now I'm editing draft)

My proposal: I'm going to handle this by simplifying the para so it
reads:
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 signals to
the PCN-ingress-node about the decision about admission control. It
would ...

The reason is that the bullet a few lines earlier says 
Make decision about admission - [cut] As well as the PCN measurements,
the decision takes account of policy and application layer requirements.

Ie we don't need to repeat this again.

Hopefully ok?

phil

> -----Original Message-----
> From: Tina TSOU [mailto:[email-masked]]
> Sent: 13 July 2007 10:27
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Subject: Re: [PCN] Fwd: I-D
ACTION:draft-eardley-pcn-architecture-00.txt
> 
> Sorry, forgot to delete "policy and". They should be display as below.
> 
> > 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 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: "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
> 
> 
> > 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
> >
> > 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/
> >
> >> -----Original Message-----
> >> From: Tina TSOU [mailto:[email-masked]]
> >> Sent: 11 July 2007 04:56
> >> To: [email-masked]; Eardley,PL,Philip,CXR9 R
> >> Subject: Re: [PCN] Fwd: I-D
> > ACTION:draft-eardley-pcn-architecture-00.txt
> >>
> >> 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
> >> 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
> >>
> >> > -----Original Message-----
> >> > From: Tina TSOU [mailto:[email-masked]]
> >> > Sent: 02 July 2007 04:38
> >> > To: [email-masked]; Eardley,PL,Philip,CXR9 R
> >> > Subject: Re: [PCN] Fwd: I-D
> >> ACTION:draft-eardley-pcn-architecture-00.txt
> >> >
> >> > 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@norte
l
> >> > .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

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

---

From: Tina TSOU <[email-masked]>
Date: Wed, 08 Aug 2007 17:40:29 +0800

Hi Phil,
Sounds excellent:)
A small comment is below.
In this scenario, if Egress does not need to reply any message to Ingress, 
it is more reasonable to let the Egress report to the centralized node.
If Egress still needs to replay some message to Ingress, a case which lets 
the Ingress report to the Centralized node could be added.
And I could not remember the scenario that the Egress must reply to Ingress. 
If someone remembers, would you remind me? :)

B. R.
Tina

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

Tina

Hopefully ok?

phil

think
earlier
with
should
the
in
control
on
be
the
traffic
It
Charter &
general
it's
that
PCN
to
understanding,
be
be
depth?
the
the
text
comparison
of
l
(pre-)
domain.
t
message
with
After
use
the
MIME-compliant
with
reader
the

---

From: <[email-masked]>
Date: Wed, 8 Aug 2007 11:10:43 +0100

> Sent: 08 August 2007 10:40
> the Ingress report to the Centralized node could be added.

[phil] I don't think this is worth doing. there seem to be lots of
variants of scenarios with centralised node. I think we've tried in the
draft to give a good indication of what they're like but I don't think
we need to ensure that we *fully* cover all of them. Because it seems
they don't really set new requirements on the marking algorithms,
behaviour of the PCN-boundary-nodes, and signalling msgs - rather the
mechanism pieces would be put together in slightly different ways 

> If someone remembers, would you remind me? :)

[phil] the scenario is when the ingress makes the adm decision (not sure
if that's what you were getting at!)

phil/
> > >> > > >List-Help:
<mailto:[email-masked]?subject=help>
> > >> > > >X-Spam-Tests:
FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106,

---

From: Tina TSOU <[email-masked]>
Date: Wed, 08 Aug 2007 18:32:26 +0800

Hi Phil,
I agree with you:)

B. R.
Tina

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2007 6:10 PM
Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

phil/