Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-CongestionNotification (PCN) Architecture) to Informational RFC

From: Fortune HUANG <[email-masked]>
Date: Thu, 26 Feb 2009 11:05:07 +0800

Hi all,

Below is the email I sent on Feb. 23, saying that I can agree with Phil's
proposal.

I am resending this comment since the email was not archived in the PCN WG
email list, sorry to bother phil, toby and Ruediger because you will receive
it again.

P.S. I finally found out that when I sent emails to the PCN WG with the "答
复:" (the "Re:" in Chinese, which was automatically created by my MS
Outlook) in the title, the emails would not be archived to the PCN WG email
list.

Best Regards,
Fortune

-----邮件原件-----
发件人: Fortune HUANG [mailto:[email-masked]] 
发送时间: 2009年2月23日 12:13
收件人: [email-masked]'; [email-masked]';
[email-masked]'
抄送: [email-masked]'
主题: 答复: [PCN] Last Call: draft-ietf-pcn-architecture
(Pre-CongestionNotification (PCN) Architecture) to Informational RFC

Hi Ruediger, Toby, Phil,

Sorry to respond to this a little late, but I can also agree with Phil's
proposal. 

Best Regards,
Fortune

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2009年2月12日 19:49
收件人: [email-masked]; [email-masked]
抄送: [email-masked]; [email-masked]
主题: RE: [PCN] Last Call: draft-ietf-pcn-architecture
(Pre-CongestionNotification (PCN) Architecture) to Informational RFC

Toby, Phil,

it is also my interest to keep the architecture as clear and non-ambiguous
as possible. I agree with Phil's proposal.

Regards,

Rudiger 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 12, 2009 12:36 PM
To: [email-masked]; [email-masked]; [email-masked]; Geib, Rüdiger
Subject: RE: [PCN] Last Call: draft-ietf-pcn-architecture
(Pre-CongestionNotification (PCN) Architecture) to Informational RFC

I think Phil's proposed "3rd way" is a good compromise as it clarifies any
potential misunderstandings. leaves the architecture flexible enough to
allow for different deployment models yet limits the choices to a manageable
number (something the AD is extremely keen to ensure). 

My belief is that we need to ensure we don't delay this document any further
than it has already been. recall that this was originally meant to have been
published over a year ago and is already 1 cycle behind on its current
charter milestone date (though that is largely as a result of the time taken
between WGLC and IETF LC). Currently the progress of several other documents
is being delayed as a result of the delays being experienced by the
architecture. What we HAVE to avoid is ending up with a perfect architecture
and system that will never be deployed because we have dithered for too long
and thus missed the opportunity to have it deployed in the real world.

Toby Moncaster

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Thu 2/12/2009 11:24
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture
(Pre-CongestionNotification (PCN) Architecture) to Informational RFC
 
Thanks for the feedback on the architecture draft. The good news is that
we're discussing a very small, fine point. However, this does mean that, I
think, we should be cautious about changes, such as introducing new
terminology, especially where everyone is already clear and in agreement
about what the draft means ie that the function making the decision about
admission or termination can be situated in various places (including a
centralised node, which I think is your interest Fortune).. 

My comments fall somewhere between the two of you.

>From a terminology point of view, there are indeed terms that are defined
with respect to physical architecture (eg PCN-boundary-node) and terms that
are defined with respect to functional architecture (eg PCN-ingress-node). I
am very comfortable with this - it reflects that sometimes the architecture
draft wants to talk about the physical & sometimes about functional
architecture. I think the terminology proposal below actually make things
worse (eg I can't tell whether your PCN-decision-node definition is physical
or functional, and it refers to PCN ingress and egress which are not
defined.)

So I'd like to suggest the following ways of handling your original
comments:-

6.2.  Flow termination : "In one approach the PCN-egress-node measures the
rate of PCN-traffic that is not excess-traffic-marked, which is the amount
of PCN-traffic that can actually be supported, and communicates this to the
PCN-ingress-node.  Also the PCN-ingress-node measures the rate of
PCN-traffic that is destined for this specific PCN-egress-node, and hence it
can calculate the excess amount that should be terminated." Comment: It is
the decision point but not the ingress node to be communicated by the egress
and to decide the amount of termination.

Proposal - Modify the last sentence: "Also the PCN-ingress-node measures the
rate of PCN-traffic that is destined for this specific PCN-egress-node. The
difference represents the excess amount that should be terminated."  

6.4.       Information transport: "Signalling is needed to transport
PCN-feedback-information between the PCN-boundary-nodes, for example to
convey the fraction of PCN-marked traffic from a PCN-egress-node to the
relevant PCN-ingress-node." 

Proposal - "Signalling is needed to transport PCN-feedback-information, for
example to convey the fraction of PCN-marked traffic from a PCN-egress-node
to the relevant PCN-ingress-node." (The definition of
PCN-feedback-information makes clear that the example is only an example.) 

7.4.  Admission control functions: "  There are various possibilities for
how the functionality could be distributed (we assume the operator would
configure which is used):    

 o  The decision is made at the PCN-egress-node and the decision (admit or
block) is signalled to the PCN-ingress-node.     [etc - cut]

Comment: I would suggest we replace the view "the decision is made at the
PCN-ingress-node or PCN-egress-node or a centralized node" by "the decision
point may be co-located with the ingress or egress, or may be deployed on a
standalone node".

Proposal - leave unaltered. I find your proposal less clear than the
original text as [1] 'ingress' and 'egress' are undefined; [2]
PCN-ingress-node / PCN-egress-node at least makes it clear that we're
talking about the ingress/egress for this particular flow ; [3] centralised
seems more obvious than standalone to me (standalone from what?
'centralised' hints that the same physical node would be making the decision
for every flow, which I guess is what you have in mind); [4] an alternative
would be to write something like "the decision may be made either at either
of the PCN-boundary-nodes relevant for the prospective or actual PCN-flow in
question, or else at a centralised node". But whilst this may be slightly
more exact, I think the meaning is much more obscure. 

7.5.  Flow termination functions: "o  (if required) Communicate
PCN-feedback-information to the node that makes the flow termination
decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],
communicate the PCN-egress-node's measurements to the PCN-ingress-node."
Comment: I suggest we remove the example sentence in order to avoid
misleading.

Proposal - leave unaltered. The architecture draft is full of examples; this
is good, as examples help understanding. It is not misleading.  

9.1.1.  System options: "o  Where flow admission and termination decisions
are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised
node,       see Appendix).  " Comment: I suggest we replace this sentence by
"o  Where flow admission and termination decisions are made: co-located with
PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone
node (see Appendix). "

Proposal - leave unaltered, for the reasons given under 7.4 comment 

9.5.  Security OAM: "o  A PCN-ingress-node receiving feedback signals about
the pre-congestion level on a non-existent aggregate, or that are
inconsistent with other signals (eg unexpected sequence numbers,
inconsistent addressing, conflicting reports of the pre-congestion level,
etc)." Comment: I suggest we replace the "PCN-ingress-node" by something
like "The decision point of admission control or flow termination".

Proposal - leave unaltered. As the text above the list of bullets makes
clear, these bullets are a list of examples of the sorts of things that the
security oam should be aware of, so an operator would expect to adapt the
list according to the particular deployment. 

Thanks

phil

-----Original Message-----

From: Fortune HUANG [mailto:[email-masked]]
Sent: 12 February 2009 10:03
To: [email-masked]; [email-masked]
Cc: Eardley,PL,Philip,CXR9 R
Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion
Notification (PCN) Architecture) to Informational RFC

Hi Rudiger,

Thank you very much for your answer. Things are getting clearer to me now.

Back to your proposal as follows:

[Rudiger]: "[RG] So I'm open to something like: .....supported, and
communicates this to the PCN-decision point (which is the PCN ingress node).
I'm also open to an entry in the terminology defining the PCN-decision point
to be the PCN ingress node and a stetement, that both terms are used
interchangeably where applicable in the document."

I agree with your proposal to add an entry in the terminology defining the
PCN-decision-point (or PCN-decision-node which I prefer). But in order to
make the draft more precise and future-proof, I suggest we use the
terminologies PCN-decision-node and PCN-ingress-node carefully and
precisely. That is to say, when refering to the admission control functions
or the flow termination functions, we use the terminology PCN-decision-node,
and when refering to other functionalities of the ingress we use terminology
PCN-ingress-node.

Here is my initial text of the definition of PCN-decision-node:

   o  PCN-decision-node: the node that makes admission and flow termination
decisions in the PCN domain. Theoretically, the PCN ingress, the PCN egress
or the centralised node can act as the PCN-decision-node. However, the
current charter of the PCN Working Group assumes only the PCN ingress act as
the PCN-decision-node. 

Your comments or revision are very welcome.

Best Regards,

Fortune

________________________________

???: [email-masked] [mailto:[email-masked]]
????: 2009?2?12? 16:36
???: [email-masked]
??: [email-masked]; [email-masked]; [email-masked]
??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion
Notification (PCN) Architecture) to Informational RFC

Hi Fortune,

of course section 7.2 of the current architecture does not describe any
details of the admission control. 

Look for  "7.4  Admission control functions" and for section "6 High level
functional architecture" determining 

that the detailed specification of admission control will follow in a
separate document.

Please carefully read the whole document before you distribute statements
like

[Fortune Huang]: "Admission control functions and Flow termination functions
are not part of the functionalities of the PCN-ingress-node (nor
PCN-egress-node in section 7.3)"

The architecture draft clearly specifies the opposite, as the quotes
following below show (I've shortened it all to the relevant text).

To answer your question: your understanding is not conforming to the
architecture. It is a fact, that admission control is an 

ingress node functionality (the egress node being the only standard
confroming alternative).

Admission Control is an ingress node functionality which will be specified
in detail by a separate document (egress nodes 

are an alternate point for implementation). 

"Admission Control" may of course be a separate logical functionality of
either each PCN ingress or egress node, but it is 

part of all physical devices which are either ingress (or egress) nodes.

If the charter is adapted, also centralised approaches may be standardised
by IETF.

Regards,

Rudiger

-------------------Quotes from the PCN architecture
draft----------------------------

"6.  High-level functional architecture

   The high-level approach is to split functionality between:

   o  [snip]

   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-nodes.  This information is
      in the form of the PCN-marked data packets (which are intercepted
      by the PCN-egress-nodes) and not signalling messages.  Generally
      PCN-ingress-nodes are flow-aware.

[RG: readers, please note that PCN-boundary-nodes are the PCN-ingress

 and the PCN-egress-node]

   The aim of this split is to keep the bulk of the network simple,
   scalable and robust, whilst confining policy, application-level and
   security interactions to the edge of the PCN-domain.  [snip]

   The PCN-boundary-nodes monitor the PCN-marked packets in order to
   extract information about the current state of the PCN-domain.  Based
   on this monitoring, a distributed decision is made about whether to
   admit a prospective new flow or whether to terminate existing
   flow(s).  Sections 7.4 and 7.5 mention various possibilities for how
   the functionality could be distributed.

6.1.  Flow admission

   [snip]

   Exactly how the admission control decision is made will be defined
   separately in informational documents.  

7.4.  Admission control functions

[snip]

   There are various possibilities for how the functionality could be
   distributed (we assume the operator would configure which is used):

   o  The decision is made at the PCN-egress-node and the decision
      (admit or block) is signalled to the PCN-ingress-node.

   o  The decision is recommended by the PCN-egress-node (admit or
      block) but the decision is definitively made by the PCN-ingress-
      node.  [snip]

   o  The decision is made at the PCN-ingress-node, [snip]

   o  The decision is made at a centralised node (see Appendix).

________________________________

From: Fortune HUANG [mailto:[email-masked]]
Sent: Thursday, February 12, 2009 7:06 AM
To: [email-masked]
Cc: [email-masked]; Geib, Rüdiger; [email-masked]
Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion
Notification (PCN) Architecture) to Informational RFC

Hi Rudiger,

Thank you very much for your response, but please let me clarify a little
bit.

PCN-ingress-node (or PCN-egress-node) is only a logical set of
functionalities and it is not a physical device. 

Please refer to section 7.2 in PCN-arch and pay attention to the fact that
the Admission control functions and Flow termination functions are not part
of the functionalities of the PCN-ingress-node (nor PCN-egress-node in
section 7.3).

We can implement both the Admission control functions and the
PCN-ingress-node on the same physical device, but it doesn't change the fact
that the Admission control functions are not part of the PCN-ingress-node.
Is this understanding correct?

Best Regards,

Fortune

________________________________

???: [email-masked] [mailto:[email-masked]]
????: 2009?2?11? 23:46
???: [email-masked]
??: [email-masked]; [email-masked]
??: RE: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion
Notification (PCN) Architecture) to Informational RFC

Hi Fortune,

any changes to the formulations you suggest should respect the current WG
charter. Please see in line for details.

Regards, 

Rudiger

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fortune HUANG
Sent: Wednesday, February 11, 2009 4:04 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion
Notification (PCN) Architecture) to Informational RFC

Hi all,

There are still some places in in draft-ietf-pcn-architecture-09 where the
"ingress/ingress-node" might be misused. Clarification or editorial changes
are required in those places. Please see the detailed comments below.

6.2.  Flow termination : "In one approach the PCN-egress-node measures the
rate of PCN-traffic that is not excess-traffic-marked, which is the amount
of PCN-traffic that can actually be supported, and communicates this to the
PCN-ingress-node.  Also the PCN-ingress-node measures the rate of
PCN-traffic that is destined for this specific PCN-egress-node, and hence it
can calculate the excess amount that should be terminated." Comment: It is
the decision point but not the ingress node to be communicated by the egress
and to decide the amount of termination. 

[RG] The charter says: "To allow for future extensions to the mechanisms and
their application to new deployment scenarios, they are logically separated
into several components, namely, encoding and transport along forward path
from marker to egress, metering of congestion information at the egress, and
transport of congestion information back to the controlling ingress."  and
later:

(5) encoding and transport of (pre-)congestion information between the
egress and the controlling domain ingress

[RG] I suggest to leave current meaning of text of the architecture as it
is, which means conforming to the WG charter. 

[RG] The charter clearly states, that currently the only decision point is
the ingress node. Your statement "it is the decision point but not the
ingress node to be communicated by the egress to decide..." raises the
impression that the ingress node can't be the decision point. The charter
says exactly the opposite, there's no other decision point than the ingress
node. So if the term "ingress node" is replaced by the "decision point", we
must add some text clearly stating the the only decision point of this
version of the architecture document is the ingress node.

[RG] So I'm open to something like: .....supported, and communicates this to
the PCN-decision point (which is the PCN ingress node). I'm also open to an
entry in the terminology defining the PCN-decision point to be the PCN
ingress node and a stetement, that both terms are used interchangeably where
applicable in the document.

6.4.       Information transport: "Signalling is needed to transport
PCN-feedback-information between the PCN-boundary-nodes, for example to
convey the fraction of PCN-marked traffic from a PCN-egress-node to the
relevant PCN-ingress-node." Comment: PCN-feedback-information should
transport from the egress to the decision point of admission control or flow
termination. 

[RG] See above. 

7.4.  Admission control functions: "  There are various possibilities for
how the functionality could be distributed (we assume the operator would
configure which is used):    

 o  The decision is made at the PCN-egress-node and the decision (admit or
block) is signalled to the PCN-ingress-node.     

o  The decision is recommended by the PCN-egress-node (admit or block) but
the decision is definitively made by the PCN-ingress-node.  The rationale is
that the PCN-egress-node naturally has the necessary information about
PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is the
policy enforcement       point [RFC2753], which polices incoming traffic to
ensure it is part of an admitted PCN-flow.    

 o  The decision is made at the PCN-ingress-node, which requires that the
PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node.
For example, it could signal the current fraction of PCN-traffic that is
PCN-marked.   

  o  The decision is made at a centralised node (see Appendix; beyond scope
of current PCN WG charter).   

 Note: Admission control functionality is not performed by normal
PCN-interior-nodes." Comment: I would suggest we replace the view "the
decision is made at the PCN-ingress-node or PCN-egress-node or a centralized
node" by "the decision point may be co-located with the ingress or egress,
or may be deployed on a standalone node". 

[RG] I suggest to leave the architecture document in a state conforming to
the WG charter. As the architecture document correctly states, centralised
decision points are beyond the scope of the current WG charter. 

7.5.  Flow termination functions: "o  (if required) Communicate
PCN-feedback-information to the node that makes the flow termination
decision.  For example, as in [I-D.briscoe-tsvwg-cl-architecture],
communicate the PCN-egress-node's measurements to the PCN-ingress-node."
Comment: I suggest we remove the example sentence in order to avoid
misleading.

[RG] I think the example is not misleading, as it is in conformance with the
current WG charter.

9.1.1.  System options: "o  Where flow admission and termination decisions
are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised
node,       see Appendix).  " Comment: I suggest we replace this sentence by
"o  Where flow admission and termination decisions are made: co-located with
PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone
node (see Appendix). "

[RG] I prefer the current statement, as the ingress or egress node being
decision points is confoming to the current charter, whereas a standalone
node as a decision point is not confoming to the current charter. Mentioning
a centralised node in brackets is fair, I think.

9.5.  Security OAM: "o  A PCN-ingress-node receiving feedback signals about
the pre-congestion level on a non-existent aggregate, or that are
inconsistent with other signals (eg unexpected sequence numbers,
inconsistent addressing, conflicting reports of the pre-congestion level,
etc)." Comment: I suggest we replace the "PCN-ingress-node" by something
like "The decision point of admission control or flow termination". 

[RG] see comment at the top. 

Best Regards,

Fortune