Subject: [PCN] Review of pcn-architecture-02 draft

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 1 Jan 2008 15:02:43 -0500

Hi Phil,

The link below provides my detailed comments and suggested new text for
draft-ietf-pcn-architecture-02.
Currently, my review covers, Section 1 through end of 5. New text to be
added is underlined and text to be deleted is crossed out. 
http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc 
http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf 

Changes of note:

- On terminology, changed PCN-boundary-node to PCN-edge-node. 
- Made several changes in Section 5.2, 5.3, 5.4 and 5.5.
- The changes in Section 5.7 on Tunneling that I made are with the
assumption that PCN marking will be conformant to RFC 4774, Specifying
Alternate Semantics for the Explicit Congestion Notification (ECN)
Field.
- Most of the other changes through out the draft are editorial.

I will send comments on remaining of the draft, Section 6 to end in few
days.

Happy New Year!

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 17 Jan 2008 11:34:20 +0100

Hi Joe,
 
some comments on your comments:

One general remark is whether we should talk of "interfaces" (instead 
of links) whenever PCN node-functionalities are addressed. Up to now, 
there's a mix in the text.

You introduce the concept of PCN functionality on either incoming or 
outgoing interfaces. PCN doesn't work, if there's a sequence of nodes

Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF, 

there's a link between node 2 and 3 without PCN functionality on 
any interface. So a domain shouldn't mix these nodes. I'd prefer 
PCN functionality on outgoing IF's, if this is closer to todays 
DiffServ implementations.

More details below. Please note that if I didn't comment a change 
you've proposed, this doesn't indicate agreement. Some of your 
comments aren't easy to understand for me.

Regards,

Ruediger

Terminology
 
[JB]: PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled
nodes that provide the PCN function to at least one traffic class that is
DiffServ scheduling;

[RG] if this needs to be changed, what about:
...PCN-enabled nodes perfoming DiffServ scheduling with PCN functionality 
to the PCN coloured traffic..

------

[JB]: PCN-boundary-node: a PCN-node that connects one PCN-domain to a
node either in another PCN-domain or in a non PCN-domain.

PCN-edge-node: a node that is at ingress or egress point to the PCN-enabled
network. Traffic entering or leaving the PCN network passes through it. Note,
PCN-boundary-node is a special case of PCN-edge-node.

[RG]: I don't understand why the terminology is changed in the stage we have 
reached. Has this been agreed in Vancouver? I also don't understand the 
difference between the definitons.

-------

3.1. Assumption 1: Trust and support of PCN function - controlled environment

[JB]: o Similarly, a PCN-edge-node has to trust that all the PCN-nodes
mark PCN traffic consistently. A link within the PCN-domain wouldn't be
able to alert...

[RG]: The original sentence "A non-PCN-node within the PCN-domain..." should 
be used. Links aren't able to alert anyway, PCN is a node or interface 
function. This comment applies to all insertions of "links" following in 
this paragraph.

-------

3.3. Assumption 3: Many flows and additional load

[JB]: We do not make explicit assumptions on how many PCN-flows are on each
bottleneck link. Performance evaluation work may clarify
whether it is necessary to make any additional assumption on
aggregation on the bottleneck link.

[RG]: This section should stay like it was and discuss the PCN assumptions 
on ingress-egress aggregates. Our assumptions on aggregation on links are 
discussed in the preceding section and any necessary changes regarding link 
aggregation should be added there.

---------

4.1. Flow admission

[JB]the algorithm: a PCN-node meters the amount of PCN-traffic on 
a link (on its incoming or outgoing links). The measurement is made 
as an aggregate of all PCN-packets on that link, and not per flow.

[RG]: please change to
.... on each of its incoming or outgoing links...
and leave the orinial text: ...on each one of its links, and not...
If it should be emphasised that this is done per link aggregate:
...on each single one of its links, and not..

________________________________

	Von: Jozef Babiarz [mailto:[email-masked]] 
	Gesendet: Dienstag, 1. Januar 2008 21:03
	An: PCN IETF
	Betreff: [PCN] Review of pcn-architecture-02 draft

	Hi Phil,

		The link below provides my detailed comments and suggested new text for draft-ietf-pcn-architecture-02.

	Currently, my review covers, Section 1 through end of 5. New text to be added is underlined and text to be deleted is crossed out. 

	http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc <http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc>  

	http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf <http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf>  

	Changes of note:

	- The changes in Section 5.7 on Tunneling that I made are with the assumption that PCN marking will be conformant to RFC 4774, Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field.

	I will send comments on remaining of the draft, Section 6 to end in few days.

		Happy New Year!

		Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 28 Jan 2008 11:42:29 -0500

Ruediger, see comments below.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: January 17, 2008 5:34 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: AW: [PCN] Review of pcn-architecture-02 draft

Hi Joe,

One general remark is whether we should talk of "interfaces" (instead 
of links) whenever PCN node-functionalities are addressed. Up to now, 
there's a mix in the text.
[Joe] Logically the PCN metering and marking is applied to a link
between two nodes. Physically, a vendor will implement metering and
marking on an interface to or from a node. My view is that in an
architecture document it should be worded so that equipment vendors have
a choice where they build the metering and marking function. 

there's a link between node 2 and 3 without PCN functionality on 
any interface. So a domain shouldn't mix these nodes. I'd prefer 
PCN functionality on outgoing IF's, if this is closer to todays 
DiffServ implementations.
[Joe] Yes. That is an issue. I'm suggesting that vendor of the node
specifies on what interface(s) PCN metering and marking is supported.
Nodes from different vendors have different metering capabilities with
metering (token bucket) being most common on incoming or ingress
interfaces. At lest, I believe that the PCN architecture should provide
freedom were vendor implements the PCN metering and marking function.
Should point out it will also depend on what method the vendor chooses
to use for metering. If a token bucket approach is used than a common
place would be ingress interface but if virtual queue approach is used
than maybe egress interface would be the place. A vendor may also
implement PCN metering and marking on both ingress and egress interfaces
of a node therefore providing support for PCN on links to and from the
node.

Regards,

Ruediger

Terminology
 
[JB]: PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled
nodes that provide the PCN function to at least one traffic class that
is
DiffServ scheduling;

[RG] if this needs to be changed, what about:
...PCN-enabled nodes perfoming DiffServ scheduling with PCN
functionality 
to the PCN coloured traffic..
[Joe] I'm OK with above, but would deleted word *coloured*.

------

PCN-edge-node: a node that is at ingress or egress point to the
PCN-enabled
network. Traffic entering or leaving the PCN network passes through it.
Note,
PCN-boundary-node is a special case of PCN-edge-node.

[RG]: I don't understand why the terminology is changed in the stage we
have 
reached. Has this been agreed in Vancouver? I also don't understand the 
difference between the definitons.
[Joe]My confusion, after reading definition for DS Boundary node in
RFC2475, I'm OK with using PCN-boundary-node. Please add reference to
RFC2475 Section 2.1.1 as definition of boundary-node.

-------

3.1. Assumption 1: Trust and support of PCN function - controlled
environment

[RG]: The original sentence "A non-PCN-node within the PCN-domain..."
should 
be used. Links aren't able to alert anyway, PCN is a node or interface 
function. This comment applies to all insertions of "links" following in

this paragraph.
[Joe]How about. "A node performing PCN metering and marking within the
PCN-domain wouldn't be able to alert that it is suffering
pre-congestion, which potentially would lead to too many PCN-flows being
admitted (or too few being terminated)."

-------

[JB]: We do not make explicit assumptions on how many PCN-flows are on
each
bottleneck link. Performance evaluation work may clarify
whether it is necessary to make any additional assumption on
aggregation on the bottleneck link.

[RG]: This section should stay like it was and discuss the PCN
assumptions 
on ingress-egress aggregates. Our assumptions on aggregation on links
are 
discussed in the preceding section and any necessary changes regarding
link 
aggregation should be added there.
[Joe] My interpolation is that Assumption 3 is about aggregate at the
point where the PCN metering and marking function is performed and not
how many flows belong to an ingress-egress aggregate. These are
different issues.  

---------

4.1. Flow admission

[RG]: please change to

	Hi Phil,

		The link below provides my detailed comments and
suggested new text for draft-ietf-pcn-architecture-02.

	Currently, my review covers, Section 1 through end of 5. New
text to be added is underlined and text to be deleted is crossed out. 

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc
<http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc>

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf
<http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf>

	Changes of note:

	- The changes in Section 5.7 on Tunneling that I made are with
the assumption that PCN marking will be conformant to RFC 4774,
Specifying Alternate Semantics for the Explicit Congestion Notification
(ECN) Field.

	I will send comments on remaining of the draft, Section 6 to end
in few days.

		Happy New Year!

		Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 29 Jan 2008 09:17:39 +0100

Joe,

my response to two of your comments in line (further down).

Where I'm not commenting I accept or agree with your 
response.

Regards,

Ruediger 

| -----Ursprüngliche Nachricht-----
| Von: Jozef Babiarz [mailto:[email-masked]] 
| Gesendet: Montag, 28. Januar 2008 17:42
| An: Geib, Rüdiger; [email-masked]
| Betreff: RE: [PCN] Review of pcn-architecture-02 draft
| 
| Ruediger, see comments below.
| 
| Regards, Joe
| email:[email-masked]
| Telephone:613-763-6098
| 
| -----Original Message-----
| From: Geib, Ruediger [mailto:[email-masked]]
| Sent: January 17, 2008 5:34 AM
| To: Babiarz, Jozef (CAR:0S03); [email-masked]
| Subject: AW: [PCN] Review of pcn-architecture-02 draft
| 
| Hi Joe,
|  
| some comments on your comments:
| 
| One general remark is whether we should talk of "interfaces" 
| (instead of links) whenever PCN node-functionalities are 
| addressed. Up to now, there's a mix in the text.
| [Joe] Logically the PCN metering and marking is applied to a 
| link between two nodes. Physically, a vendor will implement 
| metering and marking on an interface to or from a node. My 
| view is that in an architecture document it should be worded 
| so that equipment vendors have a choice where they build the 
| metering and marking function. 
| 
| 
| You introduce the concept of PCN functionality on either 
| incoming or outgoing interfaces. PCN doesn't work, if there's 
| a sequence of nodes
| 
| Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF, 
| 
| there's a link between node 2 and 3 without PCN functionality 
| on any interface. So a domain shouldn't mix these nodes. I'd 
| prefer PCN functionality on outgoing IF's, if this is closer 
| to todays DiffServ implementations.
| [Joe] Yes. That is an issue. I'm suggesting that vendor of 
| the node specifies on what interface(s) PCN metering and 
| marking is supported.
| Nodes from different vendors have different metering 
| capabilities with metering (token bucket) being most common 
| on incoming or ingress interfaces. At lest, I believe that 
| the PCN architecture should provide freedom were vendor 
| implements the PCN metering and marking function.
| Should point out it will also depend on what method the 
| vendor chooses to use for metering. If a token bucket 
| approach is used than a common place would be ingress 
| interface but if virtual queue approach is used than maybe 
| egress interface would be the place. A vendor may also 
| implement PCN metering and marking on both ingress and egress 
| interfaces of a node therefore providing support for PCN on 
| links to and from the node.
| 
| 
| More details below. Please note that if I didn't comment a 
| change you've proposed, this doesn't indicate agreement. Some 
| of your comments aren't easy to understand for me.
| 
| Regards,
| 
| Ruediger
| 
| 
| 
|  
| Terminology
|  
| [JB]: PCN-domain: a PCN-capable domain; a contiguous set of 
| PCN-enabled nodes that provide the PCN function to at least 
| one traffic class that is DiffServ scheduling;
| 
| [RG] if this needs to be changed, what about:
| ...PCN-enabled nodes perfoming DiffServ scheduling with PCN 
| functionality to the PCN coloured traffic..
| [Joe] I'm OK with above, but would deleted word *coloured*.
| 
| ------
| 
| [JB]: PCN-boundary-node: a PCN-node that connects one 
| PCN-domain to a node either in another PCN-domain or in a non 
| PCN-domain.
| 
| PCN-edge-node: a node that is at ingress or egress point to 
| the PCN-enabled network. Traffic entering or leaving the PCN 
| network passes through it.
| Note,
| PCN-boundary-node is a special case of PCN-edge-node.
| 
| [RG]: I don't understand why the terminology is changed in 
| the stage we have reached. Has this been agreed in Vancouver? 
| I also don't understand the difference between the definitons.
| [Joe]My confusion, after reading definition for DS Boundary 
| node in RFC2475, I'm OK with using PCN-boundary-node. Please 
| add reference to
| RFC2475 Section 2.1.1 as definition of boundary-node.
| 
| -------
| 
| 3.1. Assumption 1: Trust and support of PCN function - 
| controlled environment
| 
| [JB]: o Similarly, a PCN-edge-node has to trust that all the 
| PCN-nodes mark PCN traffic consistently. A link within the 
| PCN-domain wouldn't be able to alert...
| 
| [RG]: The original sentence "A non-PCN-node within the PCN-domain..."
| should
| be used. Links aren't able to alert anyway, PCN is a node or 
| interface function. This comment applies to all insertions of 
| "links" following in
| 
| this paragraph.
| [Joe]How about. "A node performing PCN metering and marking 
| within the PCN-domain wouldn't be able to alert that it is 
| suffering pre-congestion, which potentially would lead to too 
| many PCN-flows being admitted (or too few being terminated)."

*
[RG] Allright with me.
*
 
| -------
| 
| 3.3. Assumption 3: Many flows and additional load
| 
| [JB]: We do not make explicit assumptions on how many 
| PCN-flows are on each bottleneck link. Performance evaluation 
| work may clarify whether it is necessary to make any 
| additional assumption on aggregation on the bottleneck link.
| 
| [RG]: This section should stay like it was and discuss the 
| PCN assumptions on ingress-egress aggregates. Our assumptions 
| on aggregation on links are discussed in the preceding 
| section and any necessary changes regarding link aggregation 
| should be added there.
| [Joe] My interpolation is that Assumption 3 is about 
| aggregate at the point where the PCN metering and marking 
| function is performed and not how many flows belong to an 
| ingress-egress aggregate. These are different issues.  
| 

*
[RG] I understand your comment and your point of view, I think. 
"The original text referring to ingress-egress aggregates 
doesn't fit to this section" is what you say, isn't it? This 
is because this section is limited to traffic conditions at 
marking and metering nodes.
The remark about ingress egress aggregates may better fit to 
e.g. section 4. The assumptions and relevance we make on 
ingress egress aggregates needs to stay in the  draft, but 
you are right that this doesn't fit well to 3.3.

End of my comments in this mail
*

| ---------
| 
| 4.1. Flow admission
| 
| [JB]the algorithm: a PCN-node meters the amount of 
| PCN-traffic on a link (on its incoming or outgoing links). 
| The measurement is made as an aggregate of all PCN-packets on 
| that link, and not per flow.
| 
| [RG]: please change to
| .... on each of its incoming or outgoing links...
| and leave the orinial text: ...on each one of its links, and not...
| If it should be emphasised that this is done per link aggregate:
| ...on each single one of its links, and not..
| 
| ________________________________
| 
| 	Von: Jozef Babiarz [mailto:[email-masked]] 
| 	Gesendet: Dienstag, 1. Januar 2008 21:03
| 	An: PCN IETF
| 	Betreff: [PCN] Review of pcn-architecture-02 draft
| 	
| 	
| 
| 	Hi Phil,
| 
| 		The link below provides my detailed comments 
| and suggested new text for draft-ietf-pcn-architecture-02.
| 
| 	Currently, my review covers, Section 1 through end of 
| 5. New text to be added is underlined and text to be deleted 
| is crossed out. 
| 
| 	
| http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc
| <http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-0
| 2-jb.doc>
| 
| 
| 	
| http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf
| <http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-0
| 2-jb.pdf>
| 
| 
| 	Changes of note:
| 
| 	- On terminology, changed PCN-boundary-node to PCN-edge-node. 
| 
| 	- Made several changes in Section 5.2, 5.3, 5.4 and 5.5.
| 
| 	- The changes in Section 5.7 on Tunneling that I made 
| are with the assumption that PCN marking will be conformant 
| to RFC 4774, Specifying Alternate Semantics for the Explicit 
| Congestion Notification
| (ECN) Field.
| 
| 	- Most of the other changes through out the draft are editorial.
| 
| 	I will send comments on remaining of the draft, Section 
| 6 to end in few days.
| 
| 		Happy New Year!
| 
| 		Regards, Joe
| 
| 	email:[email-masked]
| 
| 	Telephone:613-763-6098
| 
|

---

From: <[email-masked]>
Date: Tue, 29 Jan 2008 12:27:50 -0000

Joe

I'm now updating the architecture draft. Thanks for your comments!

Some initial questions:

- you used the term 'PCN-edge-node' (rather than PCN-boundary-node) with
a new definition. I didn't understand why - in particular I didn't
understand what the substantive difference is between the 2 definitions

- in the abstract, you changed "..architecture for flow admission and
termination based on aggregated pre-congestion information..." by
deleting "aggregated". You also made similar change at several places in
the doc, eg possibility of PCN-egress-node making measurements per flow
(rather than per aggregate). My proposal: to leave the draft as it is,
however there'll be a new section called something like "Beyond the
current PCN charter" where I'll mention the per flow stuff. Steve Blake
recommended (off list) to have such a section, and I'm going to move all
the comments about charter scope to this new section. I think your per
flow stuff will fit best there.

- I didn't find any changes after S5, just wanted to make sure I didn't
lose them in Inbox!

More later

Thanks

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 01 January 2008 20:03
To: PCN IETF
Subject: [PCN] Review of pcn-architecture-02 draft

Hi Phil,

Changes of note:

Happy New Year!

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jan 2008 14:07:06 +0100

Hi Phil,

[email-masked] wrote:
>
> Joe
>
> I’m now updating the architecture draft. Thanks for your comments!
>
> Some initial questions:
>
> - you used the term ‘PCN-edge-node’ (rather than PCN-boundary-node) 
> with a new definition. I didn’t understand why – in particular I 
> didn’t understand what the substantive difference is between the 2 
> definitions
>
> - in the abstract, you changed “..architecture for flow admission and 
> termination based on aggregated pre-congestion information…” by 
> deleting “aggregated”.
>

I also stumbled several times over this word and don't find it neither 
necessary nor helpful since I don't really understand what it means. 
Marking is done per link where we have the aggregation. What's done with 
this marking information is left to the PCN egress node. Somehow I have 
the feeling that this "aggregated PCN information" could imply that 
measurement is required at the PCN egress. However, probing to support 
AC or marked flow termination to support FT do not require measurement 
but react to a single mark. Therefore, I don't like the use of the word 
"aggregated" in this context.

Regards,

Michael

> You also made similar change at several places in the doc, eg 
> possibility of PCN-egress-node making measurements per flow (rather 
> than per aggregate). My proposal: to leave the draft as it is, however 
> there’ll be a new section called something like “Beyond the current 
> PCN charter” where I’ll mention the per flow stuff. Steve Blake 
> recommended (off list) to have such a section, and I’m going to move 
> all the comments about charter scope to this new section. I think your 
> per flow stuff will fit best there.
>
> - I didn’t find any changes after S5, just wanted to make sure I 
> didn’t lose them in Inbox!
>
> More later
>
> Thanks
>
> phil
>
> *From:* Jozef Babiarz [mailto:[email-masked]]
> *Sent:* 01 January 2008 20:03
> *To:* PCN IETF
> *Subject:* [PCN] Review of pcn-architecture-02 draft
>
> Hi Phil,
>
> Currently, my review covers, Section 1 through end of 5. New text to 
> be added is underlined and text to be deleted is crossed out.
>
> Alternate Semantics for the Explicit Congestion Notification (ECN) Field.
>
> /Regards, Joe/
> ------------------------------------------------------------------------
>

-- 
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: <[email-masked]>
Date: Tue, 29 Jan 2008 16:00:02 -0000

Ok. the text in version 02 is quote from charter, but I see your point. 

There are some changes Joe made (eg S3.3) which do seem to be about the
bottleneck link rather than the egress behaviour, so will generally keep
the original text for them.

> From: Michael Menth [mailto:[email-masked]]
> Sent: 29 January 2008 13:07
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PCN] Review of pcn-architecture-02 draft
> 
> Hi Phil,
> 
> > - you used the term 'PCN-edge-node' (rather than PCN-boundary-node)
> > with a new definition. I didn't understand why - in particular I
> > didn't understand what the substantive difference is between the 2
> > definitions
> >
> > deleting "aggregated".
> > there'll be a new section called something like "Beyond the current
> > PCN charter" where I'll mention the per flow stuff. Steve Blake
> > recommended (off list) to have such a section, and I'm going to move
> > - I didn't find any changes after S5, just wanted to make sure I
> > didn't lose them in Inbox!
> >
> > More later
> >
> > Thanks
> >
> > phil
> >

---

From: <[email-masked]>
Date: Tue, 29 Jan 2008 16:35:23 -0000

On this interfaces vs links question. (ie whether we should talk about PCN marking operation being done on a link or at an interface)

Couple of general points:
- I think we all agree on the content & this is just a matter of phrasing.
- a change from version 00 to 01 was to change from talking about links to talking about interfaces in S5. As rudi points out, I wasn't particularly rigorous in following through this change in other sections.

this change from links to interfaces was a change suggested by someone, I think bob. Unfortunately bob is off some time at the moment [skiing accident] so I can't ask him at the moment.

Looking at rfc2475, this almost always talks about links. So I guess I'm inclined to go back to talking about links.

If you care either way, & havent already, please shout [Diffserv expertise would be good]

I'll also add a note, probably S8.1 Configuration OAM, to capture Rudi's point that need to make sure that all links do pcn (all nodes implement on either ingoing or outgoing interface). 

thanks
phil

> Sent: 29 January 2008 08:18
> To: [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Wed, 30 Jan 2008 18:36:33 -0000

Hi,

Follow-up on one specific point.

In S4.5, where it says:

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.

You deleted the final sentence. 

Steven sent me some comments off list & made a similar remark:

>   Don't agree (about having to account for "more important" traffic in

>   PCN meters.  If the PHB(s) used for PCN-managed traffic have

>   guaranteed minimum service rates (true for EF and AF) then you don't

>   need to account for other BAs' traffic volume, since they cannot

>   consume the whole pool of BW available for PCN-managed traffic.

Don't understand - I still think that the more important traffic does
need to contribute to the PCN-meter, in the case where the PCN-node is
priority scheduling it over PCN-traffic rather than dedicating capacity.
Since the more important traffic may delay PCN-pkts on the real queue,
surely it also needs to contribute to the virtual queue (*). Otherwise
pcn pkts may get delayed if there's lots of important traffic, but are
still not being pcn-marked. Having some capacity dedicated to
pcn-traffic [guaranteed minimum service rate] reduces the chances of
this happening, but it's still possible. Whereas if the important
traffic contributes to the virtual queue then the risk is greatly
reduced (ie the risk should be no worse than normal for MBAC, assuming
that the traffic characteristics of the more important traffic are
similar to those for PCN-traffic).

(*) = (terminology assumes virtual queue implementation of pcn marking
behaviour!)

thanks,

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 01 January 2008 20:03
To: PCN IETF
Subject: [PCN] Review of pcn-architecture-02 draft

Hi Phil,

Changes of note:

Happy New Year!

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: <[email-masked]>
Date: Wed, 30 Jan 2008 18:45:13 -0000

Joe

You make some comments on Section 5.7 Tunnelling, which I didn't really
understand.

After 

   An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes.  

You deleted this:

The PCN-marks shouldn't be visible outside the
   PCN-domain, which can be achieved by doing the PCN-colour function
   (Section 5.3
<http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#section-5.3>
) after all the other (PCN and tunnelling) functions.

Why? Is this because you thought it too detailed to bother saying? Or
because you think PCN-colouring isnt needed? If the latter, this is an
argument about encoding - in which case I'll ignore the issue until the
encoding draft is done. 

You added:

  Also operator may wish to tunnel PCN-traffic across a non-PCN-capable
domain.  The PCN-marks shouldn't be visible outside the PCN-domain,
which can be achieved by encapsulating PCN packets with an outer header
that does not support the PCN function (tunnel). In this mode on
decapsulation, the inner PCN-capable header is used without
modification.

I don't agree with this. if you send PCN-traffic outside the PCN-domain
then it's no longer PCN-traffic. 

You made a lot of changes to the text about "partially PCN-capable
tunnel", ie where only one tunnel endpoint is in the PCN domain

Partly I think this is to do with encoding (again, I propose to park the
text until the encoding draft has progressed). 

However:

In the case "1.  The tunnel starts outside a PCN-domain and finishes
inside it."

You wrote:

       For this scenario when the tunnel ends, the PCN-ingress node
function must be performed after decapsulation of packet.

I don't agree. The main ingress functions like policing have to be done
at the PCN-boundary-node.

Thanks,

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 01 January 2008 20:03
To: PCN IETF
Subject: [PCN] Review of pcn-architecture-02 draft

Hi Phil,

Changes of note:

Happy New Year!

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: <[email-masked]>
Date: Wed, 30 Jan 2008 18:55:45 -0000

Joe

Final follow-up to your review, capturing a few odd points that didn't
seem worth a separate thread. 

Thanks for the careful review!

phil

1.

In S1, about the bullet 

If the operator runs both the access network and the core network, one
deployment scenario is that only the core network uses PCN admission
control but per microflow policing is done at the ingress to the access
network and not at the PCN-ingress-node. Note: to aid readability, the
rest of this draft assumes that policing is done by the
PCN-ingress-nodes.

You said

[Joe B. Comment] Do not understand the below point about access network
doing policing and core networks PCN? PCN-edge-nodes need to support per
flow policing.

The idea here (from bob) is that the pcn-edge doesn't do per policing,
rather this is devolved to the access nw. cos the access is trusted by
the core to do this properly. The access nw runs some adm ctrl protocol
[say intserv/rsvp] whilst the core runs pcn. the pcn-boundary-nodes
communicate appropriate info /decisions to the access nw to enable it to
do the policing. 

I'm lacking imagination how to re-phrase the text better, any
suggestions? I guess an alternative is to delete the whole bullet, on
the basis that it's just a corner scenario & will make the reader
scratch their heads. 

2.

I thought the original PCN-domain & PCN-boundary-node definitions were
ok (the info you added to the former is covered by implication, as it's
elsewhere in the doc)

3.

I ignored your comment in S3.5. it's true, but the term PCN-packets
already includes the idea of PCN traffic classes. 

4.

In S5.3, where it says:

PCN-colour - for PCN-packets, set the DSCP and ECN fields to the
appropriate values for use outside the PCN-domain.

You said:

[Comment Joe] I believe that PCN-colour function is not needed on egress
from PCN-domain. I believe that PCN should be end-to-end like ECN. 

I guess this is something that should be discussed in the context of the
encoding draft, so I'll leave as it is for now until there's progress on
the encoding draft. 

5. I've tried to re-work text in a few places to include your case where
adm /termination decision is made on the basis that one (or a few) pkts
are pcn-marked (rather than on the basis of measurements of the
aggregate traffic on the ingress-egress-aggregate).

Thanks

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 01 January 2008 20:03
To: PCN IETF
Subject: [PCN] Review of pcn-architecture-02 draft

Hi Phil,

Changes of note:

Happy New Year!

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 31 Jan 2008 08:29:54 +0100

Phil,
 
while I'm not favouring a situation where non PCN traffic shares queues with PCN traffic I think that you are right. If this happens and the non PCN traffic has higher priority, it must be accounted for PCN.
 
Regards,
 
Ruediger

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, January 30, 2008 7:37 PM
	To: [email-masked]
	Subject: RE: [PCN] Review of pcn-architecture-02 draft

	Hi,

	In S4.5, where it says:

	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.

	>   consume the whole pool of BW available for PCN-managed traffic.

	Don't understand - I still think that the more important traffic does need to contribute to the PCN-meter, in the case where the PCN-node is priority scheduling it over PCN-traffic rather than dedicating capacity. Since the more important traffic may delay PCN-pkts on the real queue, surely it also needs to contribute to the virtual queue (*). Otherwise pcn pkts may get delayed if there's lots of important traffic, but are still not being pcn-marked. Having some capacity dedicated to pcn-traffic [guaranteed minimum service rate] reduces the chances of this happening, but it's still possible. Whereas if the important traffic contributes to the virtual queue then the risk is greatly reduced (ie the risk should be no worse than normal for MBAC, assuming that the traffic characteristics of the more important traffic are similar to those for PCN-traffic).

	(*) = (terminology assumes virtual queue implementation of pcn marking behaviour!)

	thanks,

	phil

	-----Original Message-----
	From: Jozef Babiarz [mailto:[email-masked]] 
	Sent: 01 January 2008 20:03
	To: PCN IETF
	Subject: [PCN] Review of pcn-architecture-02 draft

	Hi Phil,

	Changes of note:

	Happy New Year!

	Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 31 Jan 2008 09:36:23 +0100

Phil,
 
if the PCN domain spans across an embedded non PCN domain, then the PCN marked packets may be tunneled without the outer header supporting PCN while the PCN marks of the inner header should be left unchanged. Examples are:
 
- backbone transit using a carrier IP VPN service
- a business access connected via L2TP over DSL
 
In both cases the carrier providing connectivity may not support PCN, but the end point using that carrier connectivity product may be in a PCN domain. It is important that the tunnel starts and ends in the same PCN domain (which holds for the given examples). Once the charter allows for extended discussion, the tunnel may also connect two PCN domains.
 
This scenario should be supported, I support Joe's view. Picking up Joe's drafted text, what about the following (my changes marked):
 
A PCN domain may expand over a non PCN domain and wish to tunnel PCN-traffic across this non-PCN-capable domain. The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by encapsulating PCN packets with an outer header that does not support PCN. In this mode on decapsulation, the inner PCN-capable header is used without modification.

Deletions are hard to mark, that's why I highlighted "PCN".

I think, the scenario is somewhat similar to passing a non PCN capable node (without a tunnel) in a PCN domain.

Regards, Ruediger

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, January 30, 2008 7:45 PM
	To: [email-masked]; [email-masked]
	Subject: RE: [PCN] Review of pcn-architecture-02 draft

	Joe

	You make some comments on Section 5.7 Tunnelling, which I didn't really understand.

	After 

	   PCN-egress-nodes.  

	You deleted this:

	The PCN-marks shouldn't be visible outside the
	   PCN-domain, which can be achieved by doing the PCN-colour function
	   (Section 5.3 <http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#section-5.3> ) after all the other (PCN and tunnelling) functions.

	Why? Is this because you thought it too detailed to bother saying? Or because you think PCN-colouring isnt needed? If the latter, this is an argument about encoding - in which case I'll ignore the issue until the encoding draft is done. 

	You added:

	  Also operator may wish to tunnel PCN-traffic across a non-PCN-capable domain.  The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by encapsulating PCN packets with an outer header that does not support the PCN function (tunnel). In this mode on decapsulation, the inner PCN-capable header is used without modification.

	I don't agree with this. if you send PCN-traffic outside the PCN-domain then it's no longer PCN-traffic. 

	You made a lot of changes to the text about "partially PCN-capable tunnel", ie where only one tunnel endpoint is in the PCN domain

	Partly I think this is to do with encoding (again, I propose to park the text until the encoding draft has progressed). 

	However:

	In the case "1.  The tunnel starts outside a PCN-domain and finishes inside it."

	You wrote:

	       For this scenario when the tunnel ends, the PCN-ingress node function must be performed after decapsulation of packet.

	I don't agree. The main ingress functions like policing have to be done at the PCN-boundary-node.

	Thanks,

	phil

	-----Original Message-----
	From: Jozef Babiarz [mailto:[email-masked]] 
	Sent: 01 January 2008 20:03
	To: PCN IETF
	Subject: [PCN] Review of pcn-architecture-02 draft

	Hi Phil,

	Changes of note:

	Happy New Year!

	Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098