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

[Tina TSOU <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> 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:[e-mail]]
>> Sent: 11 July 2007 04:56
>> To: [e-mail]; 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: <[e-mail]>
>> To: <[e-mail]>; <[e-mail]>
>> 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:[e-mail]]
>> > Sent: 02 July 2007 04:38
>> > To: [e-mail]; 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: <[e-mail]>
>> > To: <[e-mail]>
>> > 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:[e-mail]]
>> > > Sent: 22 June 2007 04:38
>> > > To: [e-mail]
>> > > 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: [e-mail]
>> > > >Cc:
>> > > >From: [e-mail]
>> > > >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: [e-mail]
>> > > >X-Mailman-Version: 2.1.5
>> > > >Reply-To: [e-mail]
>> > > >List-Id: i-d-announce.ietf.org
>> > > >List-Unsubscribe:
>> > <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>> > > >  <mailto:[e-mail]?subject=unsubscribe>
>> > > >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>> > > >List-Post: <mailto:[e-mail]>
>> > > >List-Help: <mailto:[e-mail]?subject=help>
>> > > >List-Subscribe:
>> > <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>> > > >  <mailto:[e-mail]?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: [e-mail]
>> > > >X-SMTP-RCPT-TO:
>> > >
>> >
>>
>>[e-mail],[e-mail],[e-mail],bharrath@nortel
>> > .c
>> > >
>> >
>>
> om,[e-mail],[e-mail],[e-mail],simmonds@nortel
>> > .c
>> > >
>> >
>>
> om,[e-mail],[e-mail],[e-mail],khchan@nortel.c
>> > 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
>> > > >[e-mail] 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:
>> > > >         [e-mail].
>> > > >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: <[e-mail]>
>> > > >
>> > > >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
>> > > >[e-mail]
>> > > >https://www1.ietf.org/mailman/listinfo/i-d-announce
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > PCN mailing list
>> > > [e-mail]
>> > > https://www1.ietf.org/mailman/listinfo/pcn
>> >
>> >
>> > _______________________________________________
>> > PCN mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/pcn
>
>
>
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pcn 



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