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

[Tina TSOU <[e-mail]>]

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