From pcn-bounces@ietf.org Tue Jan 01 15:03:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nKN-0002g1-KM; Tue, 01 Jan 2008 15:03:07 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J9nKM-0002ft-Fa for pcn-confirm+ok@megatron.ietf.org; Tue, 01 Jan 2008 15:03:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nKM-0002fj-5p for pcn@ietf.org; Tue, 01 Jan 2008 15:03:06 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9nKL-0005yS-H7 for pcn@ietf.org; Tue, 01 Jan 2008 15:03:06 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m01K31p00604 for ; Tue, 1 Jan 2008 20:03:01 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Jan 2008 15:02:43 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0g== From: "Jozef Babiarz" To: "PCN IETF" X-Spam-Score: -4.0 (----) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [PCN] Review of pcn-architecture-02 draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2018432823==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2018432823== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84CB1.46A22CB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84CB1.46A22CB3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.=20 http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc=20 http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf=20 Changes of note: - On terminology, changed PCN-boundary-node to PCN-edge-node.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C84CB1.46A22CB3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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-architectur= e-02-jb.doc

http://standards.nortel.com/pcn/draft-ietf-pcn-architectur= e-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:babiarz@nortel.com

Telephone:613-763-6098

------_=_NextPart_001_01C84CB1.46A22CB3-- --===============2018432823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============2018432823==-- From pcn-bounces@ietf.org Thu Jan 03 19:44:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAafY-0006qV-LR; Thu, 03 Jan 2008 19:44:16 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JAafX-0006qL-SS for pcn-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 19:44:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAafX-0006q9-Hf for pcn@ietf.org; Thu, 03 Jan 2008 19:44:15 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAafO-0003R9-JY for pcn@ietf.org; Thu, 03 Jan 2008 19:44:15 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m040i3ow024880; Thu, 3 Jan 2008 19:44:03 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Thu, 3 Jan 2008 19:44:03 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m040hWTs018985; Thu, 3 Jan 2008 19:43:58 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 19:43:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Thu, 3 Jan 2008 19:35:54 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085E51@CORPUSMX20A.corp.emc.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3439A@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling thread-index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QAGbMXgAAt1T+AA8fzNIASySaVQCFpFwVA= References: <75A199C5D243C741BF3D3F1EBCEF9BA503B3439A@E03MVZ1-UKDY.domain1.systemhost.net> To: , X-OriginalArrivalTime: 04 Jan 2008 00:43:38.0242 (UTC) FILETIME=[D84C0620:01C84E6A] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, HTML_70_90 0.1, HTML_NO_HTTP 0.1, SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: 86914b0033efd24523ee4a427c36d849 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2082892938==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2082892938== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84E69.C3C1D6B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84E69.C3C1D6B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, this looks ok. =20 Sorry for the delayed reply, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Thursday, November 22, 2007 7:13 AM To: Black, David; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =09 =09 David,=20 I tried to improve the draft to reflect your comments, is it ok? =20 [from draft-pcn-architecture-02 S5.7] =20 Potential issues arise for a "partially PCN-capable tunnel", ie where only one tunnel endpoint is in the PCN domain: =20 1. The tunnel starts outside a PCN-domain and finishes inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre- congestion. =20 2. The tunnel starts inside a PCN-domain and finishes outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated which could potentially confuse nodes beyond the tunnel egress. =20 In line with the solution for partially capable DiffServ tunnels in [2983], the following rules are applied: =20 o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the 'copy on decapsulation' rule above. =20 o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the 'copy on encapsulation' rule above. =20 Note that the above implies that one has to know, or figure out, the characteristics of the other end of the tunnel as part of setting it up. =20 Ok? =20 Also, in S6 there's listed an Open issue: o Scenarios with only one tunnel endpoint in the PCN domain may make it harder for the PCN-egress-node to gather from the signalling messages (eg RSVP, NSIS) the identity of the PCN-ingress-node. =20 Any comments? =20 Thanks phil =20 =20 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: 29 October 2007 19:58 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Cc: Black_David@emc.com Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 As the author of RFC 2983, I was going to point you to this text. =20 Regarding the characteristics of the other end of the tunnel, there isn't any magic; one has to know this (or figure it out) as part of setting up the tunnel. RFC 2983 was written from a core networks point of view so the expected sort of tunnel is one being used for traffic management, so its reasonable to expect that the nature of the other endpoint is known when the tunnel is set up. =20 If in doubt, clearing out everything (e.g., DSCP of 0) is generally a good course of action for a tunnel headed elsewhere, and if the tunnel winds up back in the same domain, unbeknownst to the admins, shame on those who weren't paying attention. =20 Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, October 24, 2007 3:06 PM To: acharny@cisco.com; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling Anna, =20 I don't know. =20 For inspiration, I looked at rfc2983, diffserv & tunnels. S3.2 of this talks about partially capable DS configs - only tunnel ingress is DS-capable but not the egress. It says that=20 If tunnel decapsulation processing discards the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable tunnel ingress node is obligated to set the inner header's DSCP to a value compatible with the network at the tunnel egress. The value 0 [is a good suggestion] =20 this approach is along the same lines to the one in the original email below. Unfortunately 2983 doesn't say how the tunnel ingress node knows about the characteristics of the network at the tunnel egress. Did the DS people have anything in mind that might apply in the PCN case? =20 phil =20 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: 24 October 2007 14:30 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Hi Phil, =20 Question: what would be the mechanism for knowing whether the egress of the tunnel is in the PCN domain or not? Are we assuming that a node somehow advertises its PCN capability? I do not think we ever explicitly assumed that? =20 Anna=20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, October 24, 2007 6:24 AM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C84E69.C3C1D6B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, this looks ok.
 
Sorry for the delayed reply,
--David

----------------------------------------------------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508)=20 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 394-7754
----------------------------------------------------

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Thursday, November 22, = 2007=20 7:13 AM
To: Black, David; pcn@ietf.org
Subject: = RE: [PCN]=20 PCN & tunnelling

David,=20

I tried to = improve=20 the draft to reflect your comments, is it ok?

 

[from=20 draft-pcn-architecture-02 S5.7]

 

Potential issues arise for a =
"partially PCN-capable tunnel", ie where
   only one tunnel endpoint is in the PCN =
domain:
 
   1.  The =
tunnel starts outside a PCN-domain and finishes inside =
it.
       If the =
packet arrives at the tunnel ingress with the =
same
       encoding =
as used within the PCN-domain to indicate =
PCN-marking,
       then this could lead the =
PCN-egress-node to falsely measure pre-
       =
congestion.
 
   2.  The =
tunnel starts inside a PCN-domain and finishes outside =
it.
       If the =
packet arrives at the tunnel ingress already =
PCN-marked,
       then it will still have the =
same encoding when it's decapsulated
       which could potentially =
confuse nodes beyond the tunnel egress.
 
   In line with the =
solution for partially capable DiffServ tunnels =
in
   [2983], the following rules are =
applied:
 
   o  For case =
(1), the tunnel egress node clears any PCN-marking on =
the
      inner =
header.  This rule is applied before the 'copy =
on
      decapsulation' =
rule above.
 
   o  For case =
(2), the tunnel ingress node clears any PCN-marking =
on
      the inner =
header.  This rule is applied after the 'copy =
on
      encapsulation' =
rule above.
 
   Note that the =
above implies that one has to know, or figure out, =
the
   characteristics of the other end =
of the tunnel as part of setting it
   up.

 

Ok?

 

Also, in S6 = there’s=20 listed an Open issue:

o  Scenarios with only one =
tunnel endpoint in the PCN domain may make
      it harder for the PCN-egress-node =
to gather from the signalling
      messages (eg RSVP, NSIS) the =
identity of the PCN-ingress-node.

 

Any=20 comments?

 

Thanks

phil

 

 

-----Original=20 Message-----
From:=20 Black_David@emc.com [mailto:Black_David@emc.com]
Sent: 29 October 2007 = 19:58
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Cc:=20 Black_David@emc.com
Subject:=20 RE: [PCN] PCN & tunnelling

 

Phil,

 

As the author of = RFC 2983,=20 I was going to point you to this text.

 

Regarding the=20 characteristics of the other end of the tunnel, = there

isn't any magic; = one has=20 to know this (or figure it out) as part of

setting up the=20 tunnel.  RFC 2983 was written from a core = networks

point of view so = the=20 expected sort of tunnel is one being used for

traffic = management, so its=20 reasonable to expect that the nature of

the other = endpoint is=20 known when the tunnel is set up.

 

If in doubt, = clearing out=20 everything (e.g., DSCP of 0) is generally

a good course of = action=20 for a tunnel headed elsewhere, and if the

tunnel winds up=20 back in the same domain, unbeknownst to the = admins,

shame on those = who weren't=20 paying attention.

 

Thanks,

--David

----------------------------------------------------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508)=20 = 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------

 

From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007 3:06=20 PM
To: = acharny@cisco.com;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN & tunnelling

Anna,

 

I = don’t=20 know.

 

For = inspiration, I=20 looked at rfc2983, diffserv & tunnels. S3.2 of this talks about=20 partially capable DS configs – only tunnel ingress is = DS-capable but not the=20 egress. It says that 

If tunnel decapsulation =
processing discards
   the outer header's =
DSCP value without changing the inner =
header's
   DSCP value, the =
DS-capable tunnel ingress node is obligated to =
set
   the inner header's DSCP to a =
value compatible with the network at the
   tunnel egress.  The value 0 [is a good =
suggestion]

 

this = approach is=20 along the same lines to the one in the original email below. = Unfortunately=20 2983 doesn’t say how the tunnel ingress node knows about the = characteristics=20 of the network at the tunnel egress. Did the DS people have anything = in mind=20 that might apply in the PCN case?

 

phil

 

-----Original=20 Message-----
From: Anna=20 Charny (acharny) [mailto:acharny@cisco.com]
Sent: 24 October 2007 = 14:30
To: Eardley,PL,Philip,CXR9 R; = pcn@ietf.org
Subject: RE:=20 [PCN] PCN & tunnelling

 

Hi=20 Phil,

 

Question: = what=20 would be the mechanism for knowing whether the egress of the tunnel = is in=20 the PCN domain or not?  Are we assuming that a node somehow = advertises=20 its PCN capability?  I do not think we ever explicitly assumed=20 that?

 

Anna=20

 

From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October = 24, 2007=20 6:24 AM
To:=20 pcn@ietf.org
Subject:=20 [PCN] PCN & tunnelling

Hi,

 

I was chatting with Bob about section = 5.8=20 tunnelling. We’ve realised there’s the following nasty = case which we=20 hadn’t thought about. The scenario is when a tunnel starts = inside a=20 PCN-domain and finishes outside it.

 

First we follow what happens when the = current text=20 is followed. Imagine that the pkt is PCN-marked by some PCN-node = before=20 the tunnel start node. On encapsulation the PCN-mark is copied = onto the=20 outer header. Hence the PCN-egress-node ‘sees’ the = PCN-mark as normal –=20 this is ok. The PCN-egress-node clears the marking in the (outer) = header=20 and forwards the pkt into the next domain. The pkt is decapsulated = at the=20 tunnel end point. But the decapsulated pkt is already PCN-marked.=20 Potential problems: [1] if it’s decapsulated in a = non-PCN-domain, then the=20 pkt may confuse nodes in this domain [depending on what encoding = is used=20 for a PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, = then the pkt=20 is PCN-marked [which might lead this PCN-domain to terminate or = block a=20 flow unnecessarily].

 

The problem arises because the = PCN-egress-node=20 clears PCN-marking on the outer header but not on the inner = header. (This=20 is a new problem compared with ECN & tunnelling.) =

 

Possible solution: if the pkt is = PCN-marked, then=20 the tunnel start node checks whether the tunnel egress is inside = or=20 outside the PCN-domain - if it’s outside, then it clears the = PCN-marking=20 on the inner header (effectively it does this on behalf of the=20 PCN-egress-node). (Also, the PCN-mark is copied onto the outer = header, as=20 the current text says.)

 

Thoughts?

 

Thanks,

Phil/=20 =  

------_=_NextPart_001_01C84E69.C3C1D6B7-- --===============2082892938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============2082892938==-- From pcn-bounces@ietf.org Mon Jan 07 17:10:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0AR-0004dz-0N; Mon, 07 Jan 2008 17:09:59 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JC0AP-0004dt-FS for pcn-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:09:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0AP-0004dl-4d for pcn@ietf.org; Mon, 07 Jan 2008 17:09:57 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC0AO-00007U-L4 for pcn@ietf.org; Mon, 07 Jan 2008 17:09:56 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m07M9tTL018298 for ; Mon, 7 Jan 2008 16:09:55 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 16:09:55 -0600 Received: from [147.117.169.126] ([147.117.169.126]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 16:09:55 -0600 Subject: Re: [PCN] Questions on probing From: Steven Blake To: pcn In-Reply-To: <1197397615.21366.38.camel@neutrino> References: <1197397615.21366.38.camel@neutrino> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 07 Jan 2008 17:09:55 -0500 Message-Id: <1199743795.3354.33.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 (2.12.2-2.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2008 22:09:55.0503 (UTC) FILETIME=[08C4BBF0:01C8517A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Tue, 2007-12-11 at 13:26 -0500, Steven Blake wrote: > During last week's meeting there was some discussion regarding the role > of probing in PCN (see the preliminary minutes): > > 1. Does there need to be any discussion of probing in the architecture > draft? > > 2. If yes to (1), is the current text in the architecture draft > essentially correct and sufficient? > > 3. Does the working group need to do protocol work on probing prior to > last call for the architecture draft? > > By the judgement of the chairs, the consensus of the room for each > question was 1 - Yes, 2 - Yes, 3 - No (and these weren't close calls). > > We are opening these questions for discussion on the list. Please > review the architecture draft -02 (especially Sec. 7) and send your > feedback to the list. I would like to wrap up the discussion this week, so if you have not already, please send your comments to this list ASAP. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 07 17:10:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0BH-0005Vq-Ae; Mon, 07 Jan 2008 17:10:51 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JC0BF-0005TE-Mk for pcn-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:10:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0BF-0005T6-CO for pcn@ietf.org; Mon, 07 Jan 2008 17:10:49 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC0BE-00008D-WD for pcn@ietf.org; Mon, 07 Jan 2008 17:10:49 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m07MAmT4018807 for ; Mon, 7 Jan 2008 16:10:48 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 16:10:48 -0600 Received: from [147.117.169.126] ([147.117.169.126]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 16:10:48 -0600 Subject: Re: [PCN] Questions on centralised control nodes From: Steven Blake To: pcn In-Reply-To: <1197403234.21366.47.camel@neutrino> References: <1197403234.21366.47.camel@neutrino> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 07 Jan 2008 17:10:47 -0500 Message-Id: <1199743847.3354.35.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 (2.12.2-2.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2008 22:10:48.0377 (UTC) FILETIME=[2848AA90:01C8517A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Tue, 2007-12-11 at 15:00 -0500, Steven Blake wrote: > During last week's meeting there was some discussion regarding the role > of centralised control nodes in PCN (see the preliminary minutes): > > 1. Does there need to be any discussion of centralized decision nodes in > the architecture draft? > > 2. If yes to (1), is the current text in the architecture draft > sufficient? > > By the judgement of the chairs, the consensus of the room for each > question was 1 - Yes, 2 - Yes. > > We are opening these questions for discussion on the list. Please > review the architecture draft -02 and send your feedback to the list. There has not been much discussion on these questions. Please send any comments to the list ASAP. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jan 17 05:24:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRum-0005ZT-JU; Thu, 17 Jan 2008 05:24:04 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JFRuk-0005ZJ-Vn for pcn-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 05:24:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRue-0005Ul-7p for pcn@ietf.org; Thu, 17 Jan 2008 05:23:56 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFRud-0000KN-Nv for pcn@ietf.org; Thu, 17 Jan 2008 05:23:56 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 17 Jan 2008 11:23:50 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jan 2008 11:23:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [PCN] Architecture document / 5. Detailed functional architecture Date: Thu, 17 Jan 2008 11:25:07 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CA87CBB@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B343D6@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture document / 5. Detailed functional architecture thread-index: Acgxq7MTUQ7YyIB6S/Sr7L4i/hUjJQANz74ACcNyJvA= References: <474D4683.4080209@ericsson.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B343D6@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Jan 2008 10:23:40.0289 (UTC) FILETIME=[074DB710:01C858F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, while going through Joe's comments on the architecture I saw that=20 the node functionalities are defined in a worrying way and=20 partially incomplete: Starting with: "5.1. PCN-interior-node functions Each interface of the PCN-domain is upgraded with the following functionality:" That means that *all* outgoing and incoming interfaces of a node=20 must support *all* functions listed? I thought metering and=20 marking to be outgoing IF requirements only. 5.2. PCN-ingress-node functions Doesn't define the egress interface functionalities of the ingress=20 node (Joe added them, but this requires an editorial review). 5.3. PCN-egress-node functions Describes the "PCN domain egress interface" requirements. The PCN=20 domain egress interface is the ingress interface of the egress node.=20 This could be said at some place here. Regards, Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jan 17 05:32:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFS3O-0006xI-EP; Thu, 17 Jan 2008 05:32:58 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JFS3M-0006wU-PF for pcn-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 05:32:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFS3M-0006wL-F7 for pcn@ietf.org; Thu, 17 Jan 2008 05:32:56 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFS3L-0006ty-8h for pcn@ietf.org; Thu, 17 Jan 2008 05:32:56 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 17 Jan 2008 11:32:54 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jan 2008 11:32:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [PCN] Review of pcn-architecture-02 draft Date: Thu, 17 Jan 2008 11:34:20 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft thread-index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrg References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 17 Jan 2008 10:32:53.0742 (UTC) FILETIME=[512FF0E0:01C858F4] X-Spam-Score: -1.0 (-) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe, =20 some comments on your comments: One general remark is whether we should talk of "interfaces" (instead=20 of links) whenever PCN node-functionalities are addressed. Up to now,=20 there's a mix in the text. You introduce the concept of PCN functionality on either incoming or=20 outgoing interfaces. PCN doesn't work, if there's a sequence of nodes Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF,=20 there's a link between node 2 and 3 without PCN functionality on=20 any interface. So a domain shouldn't mix these nodes. I'd prefer=20 PCN functionality on outgoing IF's, if this is closer to todays=20 DiffServ implementations. More details below. Please note that if I didn't comment a change=20 you've proposed, this doesn't indicate agreement. Some of your=20 comments aren't easy to understand for me. Regards, Ruediger =20 Terminology =20 [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=20 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=20 reached. Has this been agreed in Vancouver? I also don't understand the=20 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=20 be used. Links aren't able to alert anyway, PCN is a node or interface=20 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=20 on ingress-egress aggregates. Our assumptions on aggregation on links = are=20 discussed in the preceding section and any necessary changes regarding = link=20 aggregation should be added there. --------- 4.1. Flow admission [JB]the algorithm: a PCN-node meters the amount of PCN-traffic on=20 a link (on its incoming or outgoing links). The measurement is made=20 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:babiarz@nortel.com]=20 Gesendet: Dienstag, 1. Januar 2008 21:03 An: PCN IETF Betreff: [PCN] Review of pcn-architecture-02 draft =09 =09 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 21 05:50:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGuE7-0004rM-QQ; Mon, 21 Jan 2008 05:50:03 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JGuE6-0004rF-GH for pcn-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 05:50:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGuE6-0004r7-5t for pcn@ietf.org; Mon, 21 Jan 2008 05:50:02 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGuE5-0001Ut-Of for pcn@ietf.org; Mon, 21 Jan 2008 05:50:02 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 10:49:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture document / 5. Detailed functional architecture Date: Mon, 21 Jan 2008 10:49:58 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B344AF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CA87CBB@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture document / 5. Detailed functional architecture Thread-Index: Acgxq7MTUQ7YyIB6S/Sr7L4i/hUjJQANz74ACcNyJvAAypkJIA== From: To: X-OriginalArrivalTime: 21 Jan 2008 10:49:58.0406 (UTC) FILETIME=[5D964260:01C85C1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger Thanks - will think about how to tweak this - don't want to put anything which is too implementation specific. phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 17 January 2008 10:25 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: [PCN] Architecture document / 5. Detailed functional architecture >=20 > Hi Phil, >=20 > while going through Joe's comments on the architecture I saw that > the node functionalities are defined in a worrying way and > partially incomplete: >=20 > Starting with: >=20 > "5.1. PCN-interior-node functions >=20 > Each interface of the PCN-domain is upgraded with the following > functionality:" >=20 > That means that *all* outgoing and incoming interfaces of a node > must support *all* functions listed? I thought metering and > marking to be outgoing IF requirements only. >=20 > 5.2. PCN-ingress-node functions >=20 > Doesn't define the egress interface functionalities of the ingress > node (Joe added them, but this requires an editorial review). >=20 >=20 > 5.3. PCN-egress-node functions > Describes the "PCN domain egress interface" requirements. The PCN > domain egress interface is the ingress interface of the egress node. > This could be said at some place here. >=20 > Regards, >=20 > Ruediger >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 22 17:18:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRRv-0003LA-DC; Tue, 22 Jan 2008 17:18:31 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JHRRt-0003L4-UN for pcn-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 17:18:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRRt-0003Kw-JC for pcn@ietf.org; Tue, 22 Jan 2008 17:18:29 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHRRr-0001rO-DU for pcn@ietf.org; Tue, 22 Jan 2008 17:18:29 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0MMIMD29030; Tue, 22 Jan 2008 22:18:22 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture document / 5. Detailed functional architecture Date: Tue, 22 Jan 2008 17:18:20 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465141BB463@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B344AF@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture document / 5. Detailed functional architecture Thread-Index: Acgxq7MTUQ7YyIB6S/Sr7L4i/hUjJQANz74ACcNyJvAAypkJIABJ7DmA References: <1B6169C658325341A3B8066E23919E1CA87CBB@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B344AF@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger, Phil, In the architecture draft we need to state that the metering and marking function can be done on income interface or outgoing interface or both. It should be left up to the equipment vendor to decide where the metering and marking function is performed as long as it's specified in the product so the network administrator knows where metering and marking is performed. The metering and marking needs to be done on the link between the two nodes, so it does not matter which interface does the function. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: January 21, 2008 5:50 AM To: Ruediger.Geib@t-systems.com Cc: pcn@ietf.org Subject: RE: [PCN] Architecture document / 5. Detailed functional architecture Hi Ruediger Thanks - will think about how to tweak this - don't want to put anything which is too implementation specific. phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 17 January 2008 10:25 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: [PCN] Architecture document / 5. Detailed functional architecture >=20 > Hi Phil, >=20 > while going through Joe's comments on the architecture I saw that > the node functionalities are defined in a worrying way and > partially incomplete: >=20 > Starting with: >=20 > "5.1. PCN-interior-node functions >=20 > Each interface of the PCN-domain is upgraded with the following > functionality:" >=20 > That means that *all* outgoing and incoming interfaces of a node > must support *all* functions listed? I thought metering and > marking to be outgoing IF requirements only. >=20 > 5.2. PCN-ingress-node functions >=20 > Doesn't define the egress interface functionalities of the ingress > node (Joe added them, but this requires an editorial review). >=20 >=20 > 5.3. PCN-egress-node functions > Describes the "PCN domain egress interface" requirements. The PCN > domain egress interface is the ingress interface of the egress node. > This could be said at some place here. >=20 > Regards, >=20 > Ruediger >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 25 09:37:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIPgC-000088-Ub; Fri, 25 Jan 2008 09:37:16 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JIPgC-000080-JI for pcn-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 09:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIPgB-00007s-V1 for pcn@ietf.org; Fri, 25 Jan 2008 09:37:15 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIPgB-00080D-G0 for pcn@ietf.org; Fri, 25 Jan 2008 09:37:15 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0PEbBHX018035; Fri, 25 Jan 2008 16:37:13 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 16:37:08 +0200 Received: from esdhcp03640.research.nokia.com ([172.21.36.40]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 16:37:08 +0200 Message-Id: <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> From: Lars Eggert To: ext Jozef Babiarz In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PCN] Architecture draft- bi-directional flows Date: Fri, 25 Jan 2008 16:37:06 +0200 References: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 25 Jan 2008 14:37:08.0757 (UTC) FILETIME=[C38FC450:01C85F5F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: PCN IETF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, On 2007-12-17, at 16:58, ext Jozef Babiarz wrote: > I believe that the PCN Architecture draft needs to discuss and explain > how admission control and flow termination works at high level for > telephony and video conferencing applications and that both, telephony > and video conferencing applications have bi-directional flows. For > admission control a new flow can not be admitted unless the traffic > level on both unidirectional paths is below the PCN-lower-rate. As > well > for flow termination, a bi-directional flow is terminated if one of > the > unidirectional paths is in excess of PCN-upper-rate. can you elaborate a bit why something more is needed than simply setting up both directions independently, and failing if that didn't work? Or, for termination, when the app realizes that one direction got torn down, it tears down the other direction? Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 28 11:38:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX0G-0000qR-IP; Mon, 28 Jan 2008 11:38:36 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJX0F-0000qI-VY for pcn-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:38:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX0F-0000q8-Km for pcn@ietf.org; Mon, 28 Jan 2008 11:38:35 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJX0F-0000h3-8M for pcn@ietf.org; Mon, 28 Jan 2008 11:38:35 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m0SGcYeb029404 for ; Mon, 28 Jan 2008 10:38:34 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:38:34 -0600 Received: from [147.117.169.126] ([147.117.169.126]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:38:33 -0600 Subject: Re: [PCN] Questions on centralised control nodes From: Steven Blake To: pcn In-Reply-To: <1197403234.21366.47.camel@neutrino> References: <1197403234.21366.47.camel@neutrino> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 28 Jan 2008 11:38:33 -0500 Message-Id: <1201538313.3579.15.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2008 16:38:34.0255 (UTC) FILETIME=[394BC9F0:01C861CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Tue, 2007-12-11 at 15:00 -0500, Steven Blake wrote: > During last week's meeting there was some discussion regarding the role > of centralised control nodes in PCN (see the preliminary minutes): > > 1. Does there need to be any discussion of centralized decision nodes in > the architecture draft? > > 2. If yes to (1), is the current text in the architecture draft > sufficient? > > By the judgement of the chairs, the consensus of the room for each > question was 1 - Yes, 2 - Yes. > > We are opening these questions for discussion on the list. Please > review the architecture draft -02 and send your feedback to the list. In the absence of any opposing comments, we will proceed with these assumptions. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 28 11:42:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX4H-0001HB-BY; Mon, 28 Jan 2008 11:42:45 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJX4G-0001CG-4T for pcn-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:42:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX4F-0001C8-Oj for pcn@ietf.org; Mon, 28 Jan 2008 11:42:43 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJX4E-0000lq-W1 for pcn@ietf.org; Mon, 28 Jan 2008 11:42:43 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0SGgax28241; Mon, 28 Jan 2008 16:42:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Mon, 28 Jan 2008 11:42:29 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465142BF191@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrgARhW3tA= References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger, see comments below. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: January 17, 2008 5:34 AM To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: AW: [PCN] Review of pcn-architecture-02 draft Hi Joe, =20 some comments on your comments: One general remark is whether we should talk of "interfaces" (instead=20 of links) whenever PCN node-functionalities are addressed. Up to now,=20 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.=20 You introduce the concept of PCN functionality on either incoming or=20 outgoing interfaces. PCN doesn't work, if there's a sequence of nodes Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF,=20 there's a link between node 2 and 3 without PCN functionality on=20 any interface. So a domain shouldn't mix these nodes. I'd prefer=20 PCN functionality on outgoing IF's, if this is closer to todays=20 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=20 you've proposed, this doesn't indicate agreement. Some of your=20 comments aren't easy to understand for me. Regards, Ruediger =20 Terminology =20 [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=20 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=20 reached. Has this been agreed in Vancouver? I also don't understand the=20 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=20 be used. Links aren't able to alert anyway, PCN is a node or interface=20 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)." ------- 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=20 on ingress-egress aggregates. Our assumptions on aggregation on links are=20 discussed in the preceding section and any necessary changes regarding link=20 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. =20 --------- 4.1. Flow admission [JB]the algorithm: a PCN-node meters the amount of PCN-traffic on=20 a link (on its incoming or outgoing links). The measurement is made=20 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:babiarz@nortel.com]=20 Gesendet: Dienstag, 1. Januar 2008 21:03 An: PCN IETF Betreff: [PCN] Review of pcn-architecture-02 draft =09 =09 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.=20 =09 http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc =09 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 28 11:54:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXFH-0004Ql-Og; Mon, 28 Jan 2008 11:54:07 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJXFG-0004Qd-S4 for pcn-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:54:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXFG-0004QU-GT for pcn@ietf.org; Mon, 28 Jan 2008 11:54:06 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJXFF-00020p-Pu for pcn@ietf.org; Mon, 28 Jan 2008 11:54:06 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0SGlDVP005987; Mon, 28 Jan 2008 10:47:14 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:47:13 -0600 Received: from [147.117.169.126] ([147.117.169.126]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:47:13 -0600 Subject: RE: [PCN] Questions on probing From: Steven Blake To: philip.eardley@bt.com In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 28 Jan 2008 11:47:12 -0500 Message-Id: <1201538832.3579.22.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2008 16:47:13.0339 (UTC) FILETIME=[6EB1B8B0:01C861CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Philip, Did you and Georgios come to some agreement on how to revise the probing text in the architecture draft? By my judgement the rough consensus of the working group is that: - we *will* discuss probing in the architecture draft - we *will not* start any protocol work on probing. I would like to see us get agreement on the probing text in the architecture draft ASAP. Thanks. On Thu, 2007-12-13 at 16:44 +0000, philip.eardley@bt.com wrote: > Great, we're in violent agreement that I need to clarify this! > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 13 December 2007 16:07 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Hi Phil > > > > Sorry, but reading the text in Section 7.3 it gives me the impression > that > > the architecture draft is trying to get out of the PCN scope the > feature > > that provides > > admission control when probing is used. > > > > The given argumentation on the aggregation issue is in my opinion only > > valid > > for some > > implementations/scenarios and cannot be extrapolated to cover all > possible > > scenarios/implementations > > that are covered by the PCN scope. > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: donderdag 13 december 2007 15:46 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > I don't see why this depends on implementation. Surely it > > > depends on the scenario. The scenario I was thinking of was > > > where the PCN-domain reaches out towards the end terminals > > > where link capacity is low. (Well that could be better > > > written - it's possible that there might be high link > > > capacity near the end terminals, but normally link cap is > > > lower near the edge.) Low link cap, in general, breaks the > > > aggregation assumption. > > > > > > Now there're some people who have in mind using PCN in such > > > scenarios, and doing adm ctrl by probing (for all new flows). > > > The text does not make any judgement about whether such an > > > approach is feasible, merely that it's out of the current scope. > > > > > > phil > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 13 December 2007 14:34 > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > pcn@ietf.org > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > Hi Phil > > > > > > > > My point is that I do not agree that the below bullet breaks > > > > Assumption 3 (aggregation). This depends on how the algorithm > > > is > > > > implemented and I thought that the architectural draft should not > > > describe > > > > implementation steps. > > > > > > > > > o Simply admitting the new flow has a significant risk of > leading > > > to > > > > > overload, because the PCN-domain reaches out towards the end > > > > > terminals where link capacity is low. > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > pcn@ietf.org > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > Hi Georgios > > > > > To pick up on our of your comments, which concerns the > > > archit draft > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > hence means > > > > > that > > > > > > this > > > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > > > I do not agree with this conclusion, since I do not > > > agree with the > > > > > > argumentation that the first point breaks Assumption 3 more > > > > > than the > > > > > > situation that no probing is used during admission control. > > > > > > Therefore, please remove the sentence: > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > hence means > > > > > that > > > > > > this > > > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's just that > the > > > > > section is not very clear about the context of the draft at this > > > > > point. > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > 'admission control > > > > > is always done by probing'. It assumes the following: > > > > > > > > > > o Simply admitting the new flow has a significant risk of > > > > > leading to > > > > > overload, because the PCN-domain reaches out towards the > end > > > > > terminals where link capacity is low. > > > > > > > > > > o Every admission control decision involves probing, using > the > > > > > signalling set-up message as the probe packet (eg > > > RSVP PATH). > > > > > > > > > > o The PCN-marking behaviour is such that every packet is > > > > > PCN-marked > > > > > if the flow should be blocked, hence only a single probing > > > > > packet > > > > > is needed. > > > > > > > > > > I think the first of these bullets breaks Assumption 3 > > > > > (aggregation) and hence means that this viewpoint is out > > > of scope of > > > > > the initial Charter of the PCN WG. > > > > > > > > > > phil =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 03:17:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJlee-0003Ux-2A; Tue, 29 Jan 2008 03:17:16 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJlec-0003Up-2K for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 03:17:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJleU-0003Sx-Jk for pcn@ietf.org; Tue, 29 Jan 2008 03:17:06 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJleT-0004CC-Gm for pcn@ietf.org; Tue, 29 Jan 2008 03:17:06 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Tue, 29 Jan 2008 09:17:04 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jan 2008 09:17:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [PCN] Review of pcn-architecture-02 draft Date: Tue, 29 Jan 2008 09:17:39 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CB7E137@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465142BF191@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrgARhW3tABQYgmYA== References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1CA87CCE@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB6465142BF191@zcarhxm1.corp.nortel.com> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Jan 2008 08:17:03.0923 (UTC) FILETIME=[54794030:01C8624F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, my response to two of your comments in line (further down). Where I'm not commenting I accept or agree with your=20 response. Regards, Ruediger=20 | -----Urspr=FCngliche Nachricht----- | Von: Jozef Babiarz [mailto:babiarz@nortel.com]=20 | Gesendet: Montag, 28. Januar 2008 17:42 | An: Geib, R=FCdiger; pcn@ietf.org | Betreff: RE: [PCN] Review of pcn-architecture-02 draft |=20 | Ruediger, see comments below. |=20 | Regards, Joe | email:babiarz@nortel.com | Telephone:613-763-6098 |=20 | -----Original Message----- | From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | Sent: January 17, 2008 5:34 AM | To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org | Subject: AW: [PCN] Review of pcn-architecture-02 draft |=20 | Hi Joe, | =20 | some comments on your comments: |=20 | One general remark is whether we should talk of "interfaces"=20 | (instead of links) whenever PCN node-functionalities are=20 | addressed. Up to now, there's a mix in the text. | [Joe] Logically the PCN metering and marking is applied to a=20 | link between two nodes. Physically, a vendor will implement=20 | metering and marking on an interface to or from a node. My=20 | view is that in an architecture document it should be worded=20 | so that equipment vendors have a choice where they build the=20 | metering and marking function.=20 |=20 |=20 | You introduce the concept of PCN functionality on either=20 | incoming or outgoing interfaces. PCN doesn't work, if there's=20 | a sequence of nodes |=20 | Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF,=20 |=20 | there's a link between node 2 and 3 without PCN functionality=20 | on any interface. So a domain shouldn't mix these nodes. I'd=20 | prefer PCN functionality on outgoing IF's, if this is closer=20 | to todays DiffServ implementations. | [Joe] Yes. That is an issue. I'm suggesting that vendor of=20 | the node specifies on what interface(s) PCN metering and=20 | marking is supported. | Nodes from different vendors have different metering=20 | capabilities with metering (token bucket) being most common=20 | on incoming or ingress interfaces. At lest, I believe that=20 | the PCN architecture should provide freedom were vendor=20 | implements the PCN metering and marking function. | Should point out it will also depend on what method the=20 | vendor chooses to use for metering. If a token bucket=20 | approach is used than a common place would be ingress=20 | interface but if virtual queue approach is used than maybe=20 | egress interface would be the place. A vendor may also=20 | implement PCN metering and marking on both ingress and egress=20 | interfaces of a node therefore providing support for PCN on=20 | links to and from the node. |=20 |=20 | More details below. Please note that if I didn't comment a=20 | change you've proposed, this doesn't indicate agreement. Some=20 | of your comments aren't easy to understand for me. |=20 | Regards, |=20 | Ruediger |=20 |=20 |=20 | =20 | Terminology | =20 | [JB]: PCN-domain: a PCN-capable domain; a contiguous set of=20 | PCN-enabled nodes that provide the PCN function to at least=20 | one traffic class that is DiffServ scheduling; |=20 | [RG] if this needs to be changed, what about: | ...PCN-enabled nodes perfoming DiffServ scheduling with PCN=20 | functionality to the PCN coloured traffic.. | [Joe] I'm OK with above, but would deleted word *coloured*. |=20 | ------ |=20 | [JB]: PCN-boundary-node: a PCN-node that connects one=20 | PCN-domain to a node either in another PCN-domain or in a non=20 | PCN-domain. |=20 | PCN-edge-node: a node that is at ingress or egress point to=20 | the PCN-enabled network. Traffic entering or leaving the PCN=20 | network passes through it. | Note, | PCN-boundary-node is a special case of PCN-edge-node. |=20 | [RG]: I don't understand why the terminology is changed in=20 | the stage we have reached. Has this been agreed in Vancouver?=20 | I also don't understand the difference between the definitons. | [Joe]My confusion, after reading definition for DS Boundary=20 | node in RFC2475, I'm OK with using PCN-boundary-node. Please=20 | add reference to | RFC2475 Section 2.1.1 as definition of boundary-node. |=20 | ------- |=20 | 3.1. Assumption 1: Trust and support of PCN function -=20 | controlled environment |=20 | [JB]: o Similarly, a PCN-edge-node has to trust that all the=20 | PCN-nodes mark PCN traffic consistently. A link within the=20 | PCN-domain wouldn't be able to alert... |=20 | [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=20 | interface function. This comment applies to all insertions of=20 | "links" following in |=20 | this paragraph. | [Joe]How about. "A node performing PCN metering and marking=20 | within the PCN-domain wouldn't be able to alert that it is=20 | suffering pre-congestion, which potentially would lead to too=20 | many PCN-flows being admitted (or too few being terminated)." * [RG] Allright with me. * =20 | ------- |=20 | 3.3. Assumption 3: Many flows and additional load |=20 | [JB]: We do not make explicit assumptions on how many=20 | PCN-flows are on each bottleneck link. Performance evaluation=20 | work may clarify whether it is necessary to make any=20 | additional assumption on aggregation on the bottleneck link. |=20 | [RG]: This section should stay like it was and discuss the=20 | PCN assumptions on ingress-egress aggregates. Our assumptions=20 | on aggregation on links are discussed in the preceding=20 | section and any necessary changes regarding link aggregation=20 | should be added there. | [Joe] My interpolation is that Assumption 3 is about=20 | aggregate at the point where the PCN metering and marking=20 | function is performed and not how many flows belong to an=20 | ingress-egress aggregate. These are different issues. =20 |=20 * [RG] I understand your comment and your point of view, I think.=20 "The original text referring to ingress-egress aggregates=20 doesn't fit to this section" is what you say, isn't it? This=20 is because this section is limited to traffic conditions at=20 marking and metering nodes. The remark about ingress egress aggregates may better fit to=20 e.g. section 4. The assumptions and relevance we make on=20 ingress egress aggregates needs to stay in the draft, but=20 you are right that this doesn't fit well to 3.3. End of my comments in this mail * | --------- |=20 | 4.1. Flow admission |=20 | [JB]the algorithm: a PCN-node meters the amount of=20 | PCN-traffic on a link (on its incoming or outgoing links).=20 | The measurement is made as an aggregate of all PCN-packets on=20 | that link, and not per flow. |=20 | [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.. |=20 | ________________________________ |=20 | Von: Jozef Babiarz [mailto:babiarz@nortel.com]=20 | Gesendet: Dienstag, 1. Januar 2008 21:03 | An: PCN IETF | Betreff: [PCN] Review of pcn-architecture-02 draft | =09 | =09 |=20 | Hi Phil, |=20 | The link below provides my detailed comments=20 | and suggested new text for draft-ietf-pcn-architecture-02. |=20 | Currently, my review covers, Section 1 through end of=20 | 5. New text to be added is underlined and text to be deleted=20 | is crossed out.=20 |=20 | =09 | http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc | |=20 |=20 | =09 | http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf | |=20 |=20 | Changes of note: |=20 | - On terminology, changed PCN-boundary-node to PCN-edge-node.=20 |=20 | - Made several changes in Section 5.2, 5.3, 5.4 and 5.5. |=20 | - The changes in Section 5.7 on Tunneling that I made=20 | are with the assumption that PCN marking will be conformant=20 | to RFC 4774, Specifying Alternate Semantics for the Explicit=20 | Congestion Notification | (ECN) Field. |=20 | - Most of the other changes through out the draft are editorial. |=20 | I will send comments on remaining of the draft, Section=20 | 6 to end in few days. |=20 | Happy New Year! |=20 | Regards, Joe |=20 | email:babiarz@nortel.com |=20 | Telephone:613-763-6098 |=20 |=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 04:05:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJmOs-0001x4-MI; Tue, 29 Jan 2008 04:05:02 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJmOr-0001uU-G9 for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 04:05:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJmOr-0001rw-1F for pcn@ietf.org; Tue, 29 Jan 2008 04:05:01 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJmOq-0006Tu-4E for pcn@ietf.org; Tue, 29 Jan 2008 04:05:00 -0500 Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m0T8vGVl018776; Tue, 29 Jan 2008 09:57:23 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> <1201538832.3579.22.camel@neutrino> Subject: RE: [PCN] Questions on probing Date: Tue, 29 Jan 2008 09:57:10 +0100 Message-ID: <001101c86254$f4bfe210$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1201538832.3579.22.camel@neutrino> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQ X-Spam-Score: 1.2 (*) J_CHICKENPOX_52,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 29 Jan 2008 09:57:24 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Steven According to the email discussion, I expect that Phil will update the text in Section 7.3 such that the feature that provides admission control when probing is used is not considered to be out of the scope of the PCN activities. Regarding your following comment: > - we *will not* start any protocol work on probing. Your question in the original "Questions on probing" email was: > 3. Does the working group need to do protocol work on probing prior to > last call for the architecture draft? Therefore, I assume that your above observation should be: - we *will not* start any protocol work on probing prior to last call for the architecture draft Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: maandag 28 januari 2008 17:47 > To: philip.eardley@bt.com > Cc: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] Questions on probing > > Philip, > > Did you and Georgios come to some agreement on how to revise > the probing text in the architecture draft? By my judgement > the rough consensus of the working group is that: > > - we *will* discuss probing in the architecture draft > - we *will not* start any protocol work on probing. > > I would like to see us get agreement on the probing text in > the architecture draft ASAP. > > > Thanks. > > > On Thu, 2007-12-13 at 16:44 +0000, philip.eardley@bt.com wrote: > > > Great, we're in violent agreement that I need to clarify this! > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 13 December 2007 16:07 > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > Hi Phil > > > > > > Sorry, but reading the text in Section 7.3 it gives me the > > > impression > > that > > > the architecture draft is trying to get out of the PCN scope the > > feature > > > that provides > > > admission control when probing is used. > > > > > > The given argumentation on the aggregation issue is in my opinion > > > only valid for some implementations/scenarios and cannot be > > > extrapolated to cover all > > possible > > > scenarios/implementations > > > that are covered by the PCN scope. > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > Sent: donderdag 13 december 2007 15:46 > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > pcn@ietf.org > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > I don't see why this depends on implementation. Surely > it depends > > > > on the scenario. The scenario I was thinking of was where the > > > > PCN-domain reaches out towards the end terminals where link > > > > capacity is low. (Well that could be better written - it's > > > > possible that there might be high link capacity near the end > > > > terminals, but normally link cap is lower near the > edge.) Low link > > > > cap, in general, breaks the aggregation assumption. > > > > > > > > Now there're some people who have in mind using PCN in such > > > > scenarios, and doing adm ctrl by probing (for all new flows). > > > > The text does not make any judgement about whether such an > > > > approach is feasible, merely that it's out of the current scope. > > > > > > > > phil > > > > > > > > > -----Original Message----- > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > Sent: 13 December 2007 14:34 > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > pcn@ietf.org > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > Hi Phil > > > > > > > > > > My point is that I do not agree that the below bullet breaks > > > > > Assumption 3 (aggregation). This depends on how the algorithm > > > > is > > > > > implemented and I thought that the architectural draft should > > > > > not > > > > describe > > > > > implementation steps. > > > > > > > > > > > o Simply admitting the new flow has a significant risk of > > leading > > > > to > > > > > > overload, because the PCN-domain reaches out > towards the end > > > > > > terminals where link capacity is low. > > > > > > > > > > Best regards, > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > pcn@ietf.org > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > Hi Georgios > > > > > > To pick up on our of your comments, which concerns the > > > > archit draft > > > > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > hence means > > > > > > that > > > > > > > this > > > > > > > viewpoint is out of scope of initial Charter of > the PCN WG." > > > > > > > > > > > > > > I do not agree with this conclusion, since I do not > > > > agree with the > > > > > > > argumentation that the first point breaks > Assumption 3 more > > > > > > than the > > > > > > > situation that no probing is used during > admission control. > > > > > > > Therefore, please remove the sentence: > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > hence means > > > > > > that > > > > > > > this > > > > > > > viewpoint is out of scope of initial Charter of > the PCN WG." > > > > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's > just that > > the > > > > > > section is not very clear about the context of the draft at > > > > > > this point. > > > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > > 'admission control > > > > > > is always done by probing'. It assumes the following: > > > > > > > > > > > > o Simply admitting the new flow has a > significant risk of > > > > > > leading to > > > > > > overload, because the PCN-domain reaches out > towards the > > end > > > > > > terminals where link capacity is low. > > > > > > > > > > > > o Every admission control decision involves > probing, using > > the > > > > > > signalling set-up message as the probe packet (eg > > > > RSVP PATH). > > > > > > > > > > > > o The PCN-marking behaviour is such that every > packet is > > > > > > PCN-marked > > > > > > if the flow should be blocked, hence only a single > > > > > > probing packet > > > > > > is needed. > > > > > > > > > > > > I think the first of these bullets breaks Assumption 3 > > > > > > (aggregation) and hence means that this viewpoint is out > > > > of scope of > > > > > > the initial Charter of the PCN WG. > > > > > > > > > > > > phil > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 07:32:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJpdn-0005Fx-Us; Tue, 29 Jan 2008 07:32:39 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJpdm-0005F7-GN for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 07:32:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJpdm-0005C7-3N for pcn@ietf.org; Tue, 29 Jan 2008 07:32:38 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJpdl-000862-Hp for pcn@ietf.org; Tue, 29 Jan 2008 07:32:38 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 12:27:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Tue, 29 Jan 2008 12:27:50 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B344FD@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gVv4umg From: To: , X-OriginalArrivalTime: 29 Jan 2008 12:27:51.0954 (UTC) FILETIME=[5DCC8F20:01C86272] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0470467671==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0470467671== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86272.5D0B5846" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86272.5D0B5846 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe =20 I'm now updating the architecture draft. Thanks for your comments! =20 Some initial questions: =20 - 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! =20 More later =20 Thanks phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C86272.5D0B5846 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft

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:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [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.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:babiarz@nortel.com

Telephone:613-763-6098

=00 ------_=_NextPart_001_01C86272.5D0B5846-- --===============0470467671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0470467671==-- From pcn-bounces@ietf.org Tue Jan 29 08:08:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJqCO-0008Kn-K7; Tue, 29 Jan 2008 08:08:24 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJqCN-0008J7-4A for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 08:08:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJqCM-0008Iv-PK for pcn@ietf.org; Tue, 29 Jan 2008 08:08:22 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJqCK-0007Ri-JE for pcn@ietf.org; Tue, 29 Jan 2008 08:08:22 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 770D5198E4E; Tue, 29 Jan 2008 14:08:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6AFFC198E4D; Tue, 29 Jan 2008 14:08:19 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1D05A198E30; Tue, 29 Jan 2008 14:08:17 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m0TD8G909796; Tue, 29 Jan 2008 14:08:16 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id A91B96F591; Tue, 29 Jan 2008 14:07:41 +0100 (CET) Message-ID: <479F24FA.50400@informatik.uni-wuerzburg.de> Date: Tue, 29 Jan 2008 14:07:06 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] Review of pcn-architecture-02 draft References: <75A199C5D243C741BF3D3F1EBCEF9BA503B344FD@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B344FD@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: > > Joe > > I=92m now updating the architecture draft. Thanks for your comments! > > Some initial questions: > > - you used the term =91PCN-edge-node=92 (rather than PCN-boundary-node)= =20 > with a new definition. I didn=92t understand why =96 in particular I=20 > didn=92t understand what the substantive difference is between the 2=20 > definitions > > - in the abstract, you changed =93..architecture for flow admission and= =20 > termination based on aggregated pre-congestion information=85=94 by=20 > deleting =93aggregated=94. > I also stumbled several times over this word and don't find it neither=20 necessary nor helpful since I don't really understand what it means.=20 Marking is done per link where we have the aggregation. What's done with=20 this marking information is left to the PCN egress node. Somehow I have=20 the feeling that this "aggregated PCN information" could imply that=20 measurement is required at the PCN egress. However, probing to support=20 AC or marked flow termination to support FT do not require measurement=20 but react to a single mark. Therefore, I don't like the use of the word=20 "aggregated" in this context. Regards, Michael > You also made similar change at several places in the doc, eg=20 > possibility of PCN-egress-node making measurements per flow (rather=20 > than per aggregate). My proposal: to leave the draft as it is, however=20 > there=92ll be a new section called something like =93Beyond the current= =20 > PCN charter=94 where I=92ll mention the per flow stuff. Steve Blake=20 > recommended (off list) to have such a section, and I=92m going to move=20 > all the comments about charter scope to this new section. I think your=20 > per flow stuff will fit best there. > > - I didn=92t find any changes after S5, just wanted to make sure I=20 > didn=92t lose them in Inbox! > > More later > > Thanks > > phil > > -----Original Message----- > *From:* Jozef Babiarz [mailto:babiarz@nortel.com] > *Sent:* 01 January 2008 20:03 > *To:* PCN IETF > *Subject:* [PCN] Review of pcn-architecture-02 draft > > Hi Phil, > > The link below provides my detailed comments and suggested new text=20 > for draft-ietf-pcn-architecture-02. > > Currently, my review covers, Section 1 through end of 5. New text to=20 > 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=20 > assumption that PCN marking will be conformant to RFC 4774, Specifying=20 > Alternate Semantics for the Explicit Congestion Notification (ECN) Fiel= d. > > - 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=20 > few days. > > Happy New Year! > > /Regards, Joe/ > > email:babiarz@nortel.com > > Telephone:613-763-6098 > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 09:30:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrTY-0006nY-S7; Tue, 29 Jan 2008 09:30:12 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJrTX-0006kb-4A for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 09:30:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrTW-0006iM-Op for pcn@ietf.org; Tue, 29 Jan 2008 09:30:10 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJrTW-0004Ac-50 for pcn@ietf.org; Tue, 29 Jan 2008 09:30:10 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 14:21:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture draft- bi-directional flows Date: Tue, 29 Jan 2008 14:21:03 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34504@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: AchfX9C1CRKalIWVQRSqH1x2AYFUawDIf8FQ From: To: , X-OriginalArrivalTime: 29 Jan 2008 14:21:06.0671 (UTC) FILETIME=[2FC417F0:01C86282] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Note, bi-directional flows are discussed in the arch draft already. Section 6, http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#page-24 says=20 o Bi-Directional Sessions: Many applications have bi-directional sessions - hence there are two flows that should be admitted (or terminated) as a pair - for instance a bi-directional voice call only makes sense if flows in both directions are admitted. However, PCN's mechanisms concern admission and termination of a single flow, and coordination of the decision for both flows is a matter for the signalling protocol and out of scope of PCN. One possible example would use SIP pre-conditions; there are others. Hopefully this is enough? > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 25 January 2008 14:37 > To: ext Jozef Babiarz > Cc: PCN IETF > Subject: Re: [PCN] Architecture draft- bi-directional flows >=20 > Hi, >=20 > On 2007-12-17, at 16:58, ext Jozef Babiarz wrote: > > I believe that the PCN Architecture draft needs to discuss and explain > > how admission control and flow termination works at high level for > > telephony and video conferencing applications and that both, telephony > > and video conferencing applications have bi-directional flows. For > > admission control a new flow can not be admitted unless the traffic > > level on both unidirectional paths is below the PCN-lower-rate. As > > well > > for flow termination, a bi-directional flow is terminated if one of > > the > > unidirectional paths is in excess of PCN-upper-rate. >=20 > can you elaborate a bit why something more is needed than simply > setting up both directions independently, and failing if that didn't > work? Or, for termination, when the app realizes that one direction > got torn down, it tears down the other direction? >=20 > Lars >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 09:43:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrgR-0008Go-2l; Tue, 29 Jan 2008 09:43:31 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJrgQ-0008GL-Ee for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 09:43:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrgQ-0008GB-2P for pcn@ietf.org; Tue, 29 Jan 2008 09:43:30 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJrgP-0004SV-0J for pcn@ietf.org; Tue, 29 Jan 2008 09:43:29 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 14:43:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Questions on probing Date: Tue, 29 Jan 2008 14:43:26 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <001101c86254$f4bfe210$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFA= From: To: , X-OriginalArrivalTime: 29 Jan 2008 14:43:27.0659 (UTC) FILETIME=[4F0E9FB0:01C86285] X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Georgios Currently working on draft, how about following: The third viewpoint assumes the following: o Every admission control decision involves probing, for example using the signalling set-up message as the probe packet (eg RSVP PATH). o The PCN-marking behaviour is such that every packet is PCN-marked if the flow should be blocked, hence only a single probing packet is needed. This viewpoint has in particular been suggested for the scenario where the PCN-domain reaches out to the end terminals. See section 11. Section 11 is a new section called something like "Beyond the scope of the initial charter" (suggested by steven blake) There I'll say something like (English needs tweaking): Referring to the scenario where the PCN-domain reaches out to the end terminals. Link capacity is likely to be low at the edge of the PCN-domain. This breaks Assumption 3 (aggregation) and hence further consideration is out of scope of the initial Charter of the PCN WG. It has also been suggested to probe for admission of all calls in other scenarios where Assumption 3 does hold. It has been agreed not to consider this further <...> means some text I will agree off list with Steven to make sure it is accurate (rather than bashing it on list) Phil > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 29 January 2008 08:57 > To: 'Steven Blake' > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > Subject: RE: [PCN] Questions on probing >=20 > Hi Steven >=20 > According to the email discussion, I expect that Phil will update the text > in Section 7.3 > such that the feature that provides admission control when probing is used > is not considered > to be out of the scope of the PCN activities. >=20 > Regarding your following comment: > > - we *will not* start any protocol work on probing. >=20 > Your question in the original "Questions on probing" email was: > > 3. Does the working group need to do protocol work on probing prior to > > last call for the architecture draft? >=20 > Therefore, I assume that your above observation should be: > - we *will not* start any protocol work on probing prior to > last call for the architecture draft >=20 > Best regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > Sent: maandag 28 januari 2008 17:47 > > To: philip.eardley@bt.com > > Cc: karagian@cs.utwente.nl; pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Philip, > > > > Did you and Georgios come to some agreement on how to revise > > the probing text in the architecture draft? By my judgement > > the rough consensus of the working group is that: > > > > - we *will* discuss probing in the architecture draft > > - we *will not* start any protocol work on probing. > > > > I would like to see us get agreement on the probing text in > > the architecture draft ASAP. > > > > > > Thanks. > > > > > > On Thu, 2007-12-13 at 16:44 +0000, philip.eardley@bt.com wrote: > > > > > Great, we're in violent agreement that I need to clarify this! > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 13 December 2007 16:07 > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > pcn@ietf.org > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > Hi Phil > > > > > > > > Sorry, but reading the text in Section 7.3 it gives me the > > > > impression > > > that > > > > the architecture draft is trying to get out of the PCN scope the > > > feature > > > > that provides > > > > admission control when probing is used. > > > > > > > > The given argumentation on the aggregation issue is in my opinion > > > > only valid for some implementations/scenarios and cannot be > > > > extrapolated to cover all > > > possible > > > > scenarios/implementations > > > > that are covered by the PCN scope. > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > Sent: donderdag 13 december 2007 15:46 > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > pcn@ietf.org > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > I don't see why this depends on implementation. Surely > > it depends > > > > > on the scenario. The scenario I was thinking of was where the > > > > > PCN-domain reaches out towards the end terminals where link > > > > > capacity is low. (Well that could be better written - it's > > > > > possible that there might be high link capacity near the end > > > > > terminals, but normally link cap is lower near the > > edge.) Low link > > > > > cap, in general, breaks the aggregation assumption. > > > > > > > > > > Now there're some people who have in mind using PCN in such > > > > > scenarios, and doing adm ctrl by probing (for all new flows). > > > > > The text does not make any judgement about whether such an > > > > > approach is feasible, merely that it's out of the current scope. > > > > > > > > > > phil > > > > > > > > > > > -----Original Message----- > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > Sent: 13 December 2007 14:34 > > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > > pcn@ietf.org > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > Hi Phil > > > > > > > > > > > > My point is that I do not agree that the below bullet breaks > > > > > > Assumption 3 (aggregation). This depends on how the algorithm > > > > > is > > > > > > implemented and I thought that the architectural draft should > > > > > > not > > > > > describe > > > > > > implementation steps. > > > > > > > > > > > > > o Simply admitting the new flow has a significant risk of > > > leading > > > > > to > > > > > > > overload, because the PCN-domain reaches out > > towards the end > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > Best regards, > > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > pcn@ietf.org > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > Hi Georgios > > > > > > > To pick up on our of your comments, which concerns the > > > > > archit draft > > > > > > > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > > hence means > > > > > > > that > > > > > > > > this > > > > > > > > viewpoint is out of scope of initial Charter of > > the PCN WG." > > > > > > > > > > > > > > > > I do not agree with this conclusion, since I do not > > > > > agree with the > > > > > > > > argumentation that the first point breaks > > Assumption 3 more > > > > > > > than the > > > > > > > > situation that no probing is used during > > admission control. > > > > > > > > Therefore, please remove the sentence: > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > > hence means > > > > > > > that > > > > > > > > this > > > > > > > > viewpoint is out of scope of initial Charter of > > the PCN WG." > > > > > > > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's > > just that > > > the > > > > > > > section is not very clear about the context of the draft at > > > > > > > this point. > > > > > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > > > 'admission control > > > > > > > is always done by probing'. It assumes the following: > > > > > > > > > > > > > > o Simply admitting the new flow has a > > significant risk of > > > > > > > leading to > > > > > > > overload, because the PCN-domain reaches out > > towards the > > > end > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > o Every admission control decision involves > > probing, using > > > the > > > > > > > signalling set-up message as the probe packet (eg > > > > > RSVP PATH). > > > > > > > > > > > > > > o The PCN-marking behaviour is such that every > > packet is > > > > > > > PCN-marked > > > > > > > if the flow should be blocked, hence only a single > > > > > > > probing packet > > > > > > > is needed. > > > > > > > > > > > > > > I think the first of these bullets breaks Assumption 3 > > > > > > > (aggregation) and hence means that this viewpoint is out > > > > > of scope of > > > > > > > the initial Charter of the PCN WG. > > > > > > > > > > > > > > phil > > > > > > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 09:49:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrm1-0001q5-Vs; Tue, 29 Jan 2008 09:49:17 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJrm0-0001oe-RB for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 09:49:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrm0-0001mg-Ey for pcn@ietf.org; Tue, 29 Jan 2008 09:49:16 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJrly-0001rb-32 for pcn@ietf.org; Tue, 29 Jan 2008 09:49:16 -0500 Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m0TEn8BG015666; Tue, 29 Jan 2008 15:49:11 +0100 (MET) From: "Georgios Karagiannis" To: , References: <001101c86254$f4bfe210$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] Questions on probing Date: Tue, 29 Jan 2008 15:49:04 +0100 Message-ID: <004d01c86286$1af32060$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFAAAKK5AA== X-Spam-Score: 1.2 (*) J_CHICKENPOX_52,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 29 Jan 2008 15:49:12 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil Can you please provide some more information on the below point: > It has also been suggested to probe for admission of all > calls in other scenarios where Assumption 3 does hold. It has > been agreed not to consider this further > To which other scenarios will you refer? Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 29 januari 2008 15:43 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Questions on probing > > Georgios > > Currently working on draft, how about following: > > > The third viewpoint assumes the following: > > o Every admission control decision involves probing, for > example using the signalling set-up message as the probe > packet (eg RSVP PATH). > > o The PCN-marking behaviour is such that every packet is > PCN-marked > if the flow should be blocked, hence only a single > probing packet > is needed. > > This viewpoint has in particular been suggested for the > scenario where the PCN-domain reaches out to the end > terminals. See section 11. > > Section 11 is a new section called something like "Beyond the > scope of the initial charter" (suggested by steven blake) > There I'll say something like (English needs tweaking): > > Referring to the scenario where the PCN-domain reaches out to > the end terminals. Link capacity is likely to be low at the > edge of the PCN-domain. This breaks Assumption 3 > (aggregation) and hence further consideration is out of scope > of the initial Charter of the PCN WG. > > It has also been suggested to probe for admission of all > calls in other scenarios where Assumption 3 does hold. It has > been agreed not to consider this further > > <...> means some text I will agree off list with Steven to > make sure it is accurate (rather than bashing it on list) > > Phil > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 29 January 2008 08:57 > > To: 'Steven Blake' > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > Subject: RE: [PCN] Questions on probing > > > > Hi Steven > > > > According to the email discussion, I expect that Phil will > update the > text > > in Section 7.3 > > such that the feature that provides admission control when > probing is > used > > is not considered > > to be out of the scope of the PCN activities. > > > > Regarding your following comment: > > > - we *will not* start any protocol work on probing. > > > > Your question in the original "Questions on probing" email was: > > > 3. Does the working group need to do protocol work on > probing prior > to > > > last call for the architecture draft? > > > > Therefore, I assume that your above observation should be: > > - we *will not* start any protocol work on probing prior to > > last call for the architecture draft > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > Sent: maandag 28 januari 2008 17:47 > > > To: philip.eardley@bt.com > > > Cc: karagian@cs.utwente.nl; pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > Philip, > > > > > > Did you and Georgios come to some agreement on how to revise the > > > probing text in the architecture draft? By my judgement > the rough > > > consensus of the working group is that: > > > > > > - we *will* discuss probing in the architecture draft > > > - we *will not* start any protocol work on probing. > > > > > > I would like to see us get agreement on the probing text in the > > > architecture draft ASAP. > > > > > > > > > Thanks. > > > > > > > > > On Thu, 2007-12-13 at 16:44 +0000, philip.eardley@bt.com wrote: > > > > > > > Great, we're in violent agreement that I need to clarify this! > > > > > > > > > -----Original Message----- > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > Sent: 13 December 2007 16:07 > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > > pcn@ietf.org > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > Hi Phil > > > > > > > > > > Sorry, but reading the text in Section 7.3 it gives me the > > > > > impression > > > > that > > > > > the architecture draft is trying to get out of the > PCN scope the > > > > feature > > > > > that provides > > > > > admission control when probing is used. > > > > > > > > > > The given argumentation on the aggregation issue is in my > opinion > > > > > only valid for some implementations/scenarios and cannot be > > > > > extrapolated to cover all > > > > possible > > > > > scenarios/implementations > > > > > that are covered by the PCN scope. > > > > > > > > > > Best regards, > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > > Sent: donderdag 13 december 2007 15:46 > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > > pcn@ietf.org > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > I don't see why this depends on implementation. Surely > > > it depends > > > > > > on the scenario. The scenario I was thinking of was > where the > > > > > > PCN-domain reaches out towards the end terminals where link > > > > > > capacity is low. (Well that could be better written - it's > > > > > > possible that there might be high link capacity > near the end > > > > > > terminals, but normally link cap is lower near the > > > edge.) Low link > > > > > > cap, in general, breaks the aggregation assumption. > > > > > > > > > > > > Now there're some people who have in mind using PCN in such > > > > > > scenarios, and doing adm ctrl by probing (for all > new flows). > > > > > > The text does not make any judgement about whether such an > > > > > > approach is feasible, merely that it's out of the current > scope. > > > > > > > > > > > > phil > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > > Sent: 13 December 2007 14:34 > > > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > > > pcn@ietf.org > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > Hi Phil > > > > > > > > > > > > > > My point is that I do not agree that the below > bullet breaks > > > > > > > Assumption 3 (aggregation). This depends on how the > algorithm > > > > > > is > > > > > > > implemented and I thought that the architectural draft > should > > > > > > > not > > > > > > describe > > > > > > > implementation steps. > > > > > > > > > > > > > > > o Simply admitting the new flow has a > significant risk of > > > > leading > > > > > > to > > > > > > > > overload, because the PCN-domain reaches out > > > towards the end > > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > Best regards, > > > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > > > > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > > pcn@ietf.org > > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > > > Hi Georgios > > > > > > > > To pick up on our of your comments, which concerns the > > > > > > archit draft > > > > > > > > > > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > > > hence means > > > > > > > > that > > > > > > > > > this > > > > > > > > > viewpoint is out of scope of initial Charter of > > > the PCN WG." > > > > > > > > > > > > > > > > > > I do not agree with this conclusion, since I do not > > > > > > agree with the > > > > > > > > > argumentation that the first point breaks > > > Assumption 3 more > > > > > > > > than the > > > > > > > > > situation that no probing is used during > > > admission control. > > > > > > > > > Therefore, please remove the sentence: > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > > > hence means > > > > > > > > that > > > > > > > > > this > > > > > > > > > viewpoint is out of scope of initial Charter of > > > the PCN WG." > > > > > > > > > > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's > > > just that > > > > the > > > > > > > > section is not very clear about the context of the draft > at > > > > > > > > this point. > > > > > > > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > > > > 'admission control > > > > > > > > is always done by probing'. It assumes the following: > > > > > > > > > > > > > > > > o Simply admitting the new flow has a > > > significant risk of > > > > > > > > leading to > > > > > > > > overload, because the PCN-domain reaches out > > > towards the > > > > end > > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > > > o Every admission control decision involves > > > probing, using > > > > the > > > > > > > > signalling set-up message as the probe packet (eg > > > > > > RSVP PATH). > > > > > > > > > > > > > > > > o The PCN-marking behaviour is such that every > > > packet is > > > > > > > > PCN-marked > > > > > > > > if the flow should be blocked, hence only > a single > > > > > > > > probing packet > > > > > > > > is needed. > > > > > > > > > > > > > > > > I think the first of these bullets breaks > Assumption 3 > > > > > > > > (aggregation) and hence means that this viewpoint is out > > > > > > of scope of > > > > > > > > the initial Charter of the PCN WG. > > > > > > > > > > > > > > > > phil > > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Steven Blake > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 10:50:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsjd-0000oc-09; Tue, 29 Jan 2008 10:50:53 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJsja-0000oP-Jc for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 10:50:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsja-0000oH-7K for pcn@ietf.org; Tue, 29 Jan 2008 10:50:50 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsjY-0006Of-V4 for pcn@ietf.org; Tue, 29 Jan 2008 10:50:50 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 15:50:48 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Questions on probing Date: Tue, 29 Jan 2008 15:50:16 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34506@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <004d01c86286$1af32060$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFAAAKK5AAACB5zA From: To: , X-OriginalArrivalTime: 29 Jan 2008 15:50:48.0021 (UTC) FILETIME=[B74CF050:01C8628E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I was just going to leave it generic (" where Assumption 3 does hold"). I'm not that adding specific text is good - danger of wither just repeating the scenarios given in the Intro or else giving the impression "these are scenarios where we, the WG, think you should use probing" (cos I don't think we'll get consensus on that). Text suggestion welcome! phil=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 29 January 2008 14:49 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Questions on probing >=20 > Hi Phil >=20 > Can you please provide some more information on the below point: >=20 > > It has also been suggested to probe for admission of all > > calls in other scenarios where Assumption 3 does hold. It has > > been agreed not to consider this further > > >=20 > To which other scenarios will you refer? >=20 > Best regards, > Georgios >=20 > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: dinsdag 29 januari 2008 15:43 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Georgios > > > > Currently working on draft, how about following: > > > > > > The third viewpoint assumes the following: > > > > o Every admission control decision involves probing, for > > example using the signalling set-up message as the probe > > packet (eg RSVP PATH). > > > > o The PCN-marking behaviour is such that every packet is > > PCN-marked > > if the flow should be blocked, hence only a single > > probing packet > > is needed. > > > > This viewpoint has in particular been suggested for the > > scenario where the PCN-domain reaches out to the end > > terminals. See section 11. > > > > Section 11 is a new section called something like "Beyond the > > scope of the initial charter" (suggested by steven blake) > > There I'll say something like (English needs tweaking): > > > > Referring to the scenario where the PCN-domain reaches out to > > the end terminals. Link capacity is likely to be low at the > > edge of the PCN-domain. This breaks Assumption 3 > > (aggregation) and hence further consideration is out of scope > > of the initial Charter of the PCN WG. > > > > It has also been suggested to probe for admission of all > > calls in other scenarios where Assumption 3 does hold. It has > > been agreed not to consider this further > > > > <...> means some text I will agree off list with Steven to > > make sure it is accurate (rather than bashing it on list) > > > > Phil > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 29 January 2008 08:57 > > > To: 'Steven Blake' > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > > Subject: RE: [PCN] Questions on probing > > > > > > Hi Steven > > > > > > According to the email discussion, I expect that Phil will > > update the > > text > > > in Section 7.3 > > > such that the feature that provides admission control when > > probing is > > used > > > is not considered > > > to be out of the scope of the PCN activities. > > > > > > Regarding your following comment: > > > > - we *will not* start any protocol work on probing. > > > > > > Your question in the original "Questions on probing" email was: > > > > 3. Does the working group need to do protocol work on > > probing prior > > to > > > > last call for the architecture draft? > > > > > > Therefore, I assume that your above observation should be: > > > - we *will not* start any protocol work on probing prior to > > > last call for the architecture draft > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > Sent: maandag 28 januari 2008 17:47 > > > > To: philip.eardley@bt.com > > > > Cc: karagian@cs.utwente.nl; pcn@ietf.org > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > Philip, > > > > > > > > Did you and Georgios come to some agreement on how to revise the > > > > probing text in the architecture draft? By my judgement > > the rough > > > > consensus of the working group is that: > > > > > > > > - we *will* discuss probing in the architecture draft > > > > - we *will not* start any protocol work on probing. > > > > > > > > I would like to see us get agreement on the probing text in the > > > > architecture draft ASAP. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > On Thu, 2007-12-13 at 16:44 +0000, philip.eardley@bt.com wrote: > > > > > > > > > Great, we're in violent agreement that I need to clarify this! > > > > > > > > > > > -----Original Message----- > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > Sent: 13 December 2007 16:07 > > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > > > pcn@ietf.org > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > Hi Phil > > > > > > > > > > > > Sorry, but reading the text in Section 7.3 it gives me the > > > > > > impression > > > > > that > > > > > > the architecture draft is trying to get out of the > > PCN scope the > > > > > feature > > > > > > that provides > > > > > > admission control when probing is used. > > > > > > > > > > > > The given argumentation on the aggregation issue is in my > > opinion > > > > > > only valid for some implementations/scenarios and cannot be > > > > > > extrapolated to cover all > > > > > possible > > > > > > scenarios/implementations > > > > > > that are covered by the PCN scope. > > > > > > > > > > > > Best regards, > > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > > > Sent: donderdag 13 december 2007 15:46 > > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > > > pcn@ietf.org > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > I don't see why this depends on implementation. Surely > > > > it depends > > > > > > > on the scenario. The scenario I was thinking of was > > where the > > > > > > > PCN-domain reaches out towards the end terminals where link > > > > > > > capacity is low. (Well that could be better written - it's > > > > > > > possible that there might be high link capacity > > near the end > > > > > > > terminals, but normally link cap is lower near the > > > > edge.) Low link > > > > > > > cap, in general, breaks the aggregation assumption. > > > > > > > > > > > > > > Now there're some people who have in mind using PCN in such > > > > > > > scenarios, and doing adm ctrl by probing (for all > > new flows). > > > > > > > The text does not make any judgement about whether such an > > > > > > > approach is feasible, merely that it's out of the current > > scope. > > > > > > > > > > > > > > phil > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > > > Sent: 13 December 2007 14:34 > > > > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > > > > pcn@ietf.org > > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > > > Hi Phil > > > > > > > > > > > > > > > > My point is that I do not agree that the below > > bullet breaks > > > > > > > > Assumption 3 (aggregation). This depends on how the > > algorithm > > > > > > > is > > > > > > > > implemented and I thought that the architectural draft > > should > > > > > > > > not > > > > > > > describe > > > > > > > > implementation steps. > > > > > > > > > > > > > > > > > o Simply admitting the new flow has a > > significant risk of > > > > > leading > > > > > > > to > > > > > > > > > overload, because the PCN-domain reaches out > > > > towards the end > > > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] > > > > > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > > > pcn@ietf.org > > > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > > > > > Hi Georgios > > > > > > > > > To pick up on our of your comments, which concerns the > > > > > > > archit draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > > > > hence means > > > > > > > > > that > > > > > > > > > > this > > > > > > > > > > viewpoint is out of scope of initial Charter of > > > > the PCN WG." > > > > > > > > > > > > > > > > > > > > I do not agree with this conclusion, since I do not > > > > > > > agree with the > > > > > > > > > > argumentation that the first point breaks > > > > Assumption 3 more > > > > > > > > > than the > > > > > > > > > > situation that no probing is used during > > > > admission control. > > > > > > > > > > Therefore, please remove the sentence: > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > > > > > hence means > > > > > > > > > that > > > > > > > > > > this > > > > > > > > > > viewpoint is out of scope of initial Charter of > > > > the PCN WG." > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's > > > > just that > > > > > the > > > > > > > > > section is not very clear about the context of the draft > > at > > > > > > > > > this point. > > > > > > > > > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > > > > > 'admission control > > > > > > > > > is always done by probing'. It assumes the following: > > > > > > > > > > > > > > > > > > o Simply admitting the new flow has a > > > > significant risk of > > > > > > > > > leading to > > > > > > > > > overload, because the PCN-domain reaches out > > > > towards the > > > > > end > > > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > > > > > o Every admission control decision involves > > > > probing, using > > > > > the > > > > > > > > > signalling set-up message as the probe packet (eg > > > > > > > RSVP PATH). > > > > > > > > > > > > > > > > > > o The PCN-marking behaviour is such that every > > > > packet is > > > > > > > > > PCN-marked > > > > > > > > > if the flow should be blocked, hence only > > a single > > > > > > > > > probing packet > > > > > > > > > is needed. > > > > > > > > > > > > > > > > > > I think the first of these bullets breaks > > Assumption 3 > > > > > > > > > (aggregation) and hence means that this viewpoint is out > > > > > > > of scope of > > > > > > > > > the initial Charter of the PCN WG. > > > > > > > > > > > > > > > > > > phil > > > > > > > > > > > > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > > > Steven Blake > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 10:58:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsqu-0006xg-NY; Tue, 29 Jan 2008 10:58:24 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJsqt-0006vS-7q for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 10:58:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsqs-0006uu-QK for pcn@ietf.org; Tue, 29 Jan 2008 10:58:22 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsqr-0006Xd-GY for pcn@ietf.org; Tue, 29 Jan 2008 10:58:22 -0500 Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m0TFwBto027352; Tue, 29 Jan 2008 16:58:14 +0100 (MET) From: "Georgios Karagiannis" To: , References: <004d01c86286$1af32060$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34506@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] Questions on probing Date: Tue, 29 Jan 2008 16:58:03 +0100 Message-ID: <004e01c8628f$be21ca30$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34506@E03MVZ1-UKDY.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFAAAKK5AAACB5zAAABq+nA= X-Spam-Score: 1.2 (*) J_CHICKENPOX_52,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 29 Jan 2008 16:58:16 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil Agree with your proposal, on leaving it generic (" where Assumption 3 does hold"). Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 29 januari 2008 16:50 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Questions on probing > > I was just going to leave it generic (" where Assumption 3 > does hold"). > I'm not that adding specific text is good - danger of wither > just repeating the scenarios given in the Intro or else > giving the impression "these are scenarios where we, the WG, > think you should use probing" > (cos I don't think we'll get consensus on that). > Text suggestion welcome! > > phil > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 29 January 2008 14:49 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Hi Phil > > > > Can you please provide some more information on the below point: > > > > > It has also been suggested to probe for admission of all > > > calls in other scenarios where Assumption 3 does hold. It > has been > > > agreed not to consider this further > > > > > > > To which other scenarios will you refer? > > > > Best regards, > > Georgios > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: dinsdag 29 januari 2008 15:43 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > Georgios > > > > > > Currently working on draft, how about following: > > > > > > > > > The third viewpoint assumes the following: > > > > > > o Every admission control decision involves probing, > for example > > > using the signalling set-up message as the probe packet (eg RSVP > > > PATH). > > > > > > o The PCN-marking behaviour is such that every packet is > > > PCN-marked > > > if the flow should be blocked, hence only a single probing > > > packet > > > is needed. > > > > > > This viewpoint has in particular been suggested for > the scenario > > > where the PCN-domain reaches out to the end terminals. > See section > > > 11. > > > > > > Section 11 is a new section called something like "Beyond > the scope > > > of the initial charter" (suggested by steven blake) There > I'll say > > > something like (English needs tweaking): > > > > > > Referring to the scenario where the PCN-domain reaches out to the > > > end terminals. Link capacity is likely to be low at the > edge of the > > > PCN-domain. This breaks Assumption 3 > > > (aggregation) and hence further consideration is out of > scope of the > > > initial Charter of the PCN WG. > > > > > > It has also been suggested to probe for admission of all calls in > > > other scenarios where Assumption 3 does hold. It has been > agreed not > > > to consider this further > > > > > > <...> means some text I will agree off list with Steven > to make sure > > > it is accurate (rather than bashing it on list) > > > > > > Phil > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 29 January 2008 08:57 > > > > To: 'Steven Blake' > > > > Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > Hi Steven > > > > > > > > According to the email discussion, I expect that Phil will > > > update the > > > text > > > > in Section 7.3 > > > > such that the feature that provides admission control when > > > probing is > > > used > > > > is not considered > > > > to be out of the scope of the PCN activities. > > > > > > > > Regarding your following comment: > > > > > - we *will not* start any protocol work on probing. > > > > > > > > Your question in the original "Questions on probing" email was: > > > > > 3. Does the working group need to do protocol work on > > > probing prior > > > to > > > > > last call for the architecture draft? > > > > > > > > Therefore, I assume that your above observation should be: > > > > - we *will not* start any protocol work on probing prior to > > > > last call for the architecture draft > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > > Sent: maandag 28 januari 2008 17:47 > > > > > To: philip.eardley@bt.com > > > > > Cc: karagian@cs.utwente.nl; pcn@ietf.org > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > Philip, > > > > > > > > > > Did you and Georgios come to some agreement on how to > revise the > > > > > probing text in the architecture draft? By my judgement > > > the rough > > > > > consensus of the working group is that: > > > > > > > > > > - we *will* discuss probing in the architecture draft > > > > > - we *will not* start any protocol work on probing. > > > > > > > > > > I would like to see us get agreement on the probing > text in the > > > > > architecture draft ASAP. > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > On Thu, 2007-12-13 at 16:44 +0000, > philip.eardley@bt.com wrote: > > > > > > > > > > > Great, we're in violent agreement that I need to > clarify this! > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > > Sent: 13 December 2007 16:07 > > > > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > > > > > pcn@ietf.org > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > Hi Phil > > > > > > > > > > > > > > Sorry, but reading the text in Section 7.3 it > gives me the > > > > > > > impression > > > > > > that > > > > > > > the architecture draft is trying to get out of the > > > PCN scope the > > > > > > feature > > > > > > > that provides > > > > > > > admission control when probing is used. > > > > > > > > > > > > > > The given argumentation on the aggregation issue is in my > > > opinion > > > > > > > only valid for some implementations/scenarios and > cannot be > > > > > > > extrapolated to cover all > > > > > > possible > > > > > > > scenarios/implementations > > > > > > > that are covered by the PCN scope. > > > > > > > > > > > > > > Best regards, > > > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > > > > > > > > Sent: donderdag 13 december 2007 15:46 > > > > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > > > > > > pcn@ietf.org > > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > > > I don't see why this depends on implementation. Surely > > > > > it depends > > > > > > > > on the scenario. The scenario I was thinking of was > > > where the > > > > > > > > PCN-domain reaches out towards the end terminals where > link > > > > > > > > capacity is low. (Well that could be better > written - it's > > > > > > > > possible that there might be high link capacity > > > near the end > > > > > > > > terminals, but normally link cap is lower near the > > > > > edge.) Low link > > > > > > > > cap, in general, breaks the aggregation assumption. > > > > > > > > > > > > > > > > Now there're some people who have in mind using PCN in > such > > > > > > > > scenarios, and doing adm ctrl by probing (for all > > > new flows). > > > > > > > > The text does not make any judgement about > whether such an > > > > > > > > approach is feasible, merely that it's out of > the current > > > scope. > > > > > > > > > > > > > > > > phil > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] > > > > > > > > > Sent: 13 December 2007 14:34 > > > > > > > > > To: Eardley,PL,Philip,CXR9 R; > steven.blake@ericsson.com; > > > > > > > > pcn@ietf.org > > > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > > > > > Hi Phil > > > > > > > > > > > > > > > > > > My point is that I do not agree that the below > > > bullet breaks > > > > > > > > > Assumption 3 (aggregation). This depends on how the > > > algorithm > > > > > > > > is > > > > > > > > > implemented and I thought that the architectural draft > > > should > > > > > > > > > not > > > > > > > > describe > > > > > > > > > implementation steps. > > > > > > > > > > > > > > > > > > > o Simply admitting the new flow has a > > > significant risk of > > > > > > leading > > > > > > > > to > > > > > > > > > > overload, because the PCN-domain reaches out > > > > > towards the end > > > > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: philip.eardley@bt.com > > > [mailto:philip.eardley@bt.com] > > > > > > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > > > > > > To: karagian@cs.utwente.nl; > steven.blake@ericsson.com; > > > > > > > > pcn@ietf.org > > > > > > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > > > > > > > > > > > Hi Georgios > > > > > > > > > > To pick up on our of your comments, which > concerns the > > > > > > > > archit draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) > and > > > > > > > > hence means > > > > > > > > > > that > > > > > > > > > > > this > > > > > > > > > > > viewpoint is out of scope of initial Charter of > > > > > the PCN WG." > > > > > > > > > > > > > > > > > > > > > > I do not agree with this conclusion, > since I do not > > > > > > > > agree with the > > > > > > > > > > > argumentation that the first point breaks > > > > > Assumption 3 more > > > > > > > > > > than the > > > > > > > > > > > situation that no probing is used during > > > > > admission control. > > > > > > > > > > > Therefore, please remove the sentence: > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) > and > > > > > > > > hence means > > > > > > > > > > that > > > > > > > > > > > this > > > > > > > > > > > viewpoint is out of scope of initial Charter of > > > > > the PCN WG." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's > > > > > just that > > > > > > the > > > > > > > > > > section is not very clear about the context of the > draft > > > at > > > > > > > > > > this point. > > > > > > > > > > > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > > > > > > 'admission control > > > > > > > > > > is always done by probing'. It assumes the > following: > > > > > > > > > > > > > > > > > > > > o Simply admitting the new flow has a > > > > > significant risk of > > > > > > > > > > leading to > > > > > > > > > > overload, because the PCN-domain reaches out > > > > > towards the > > > > > > end > > > > > > > > > > terminals where link capacity is low. > > > > > > > > > > > > > > > > > > > > o Every admission control decision involves > > > > > probing, using > > > > > > the > > > > > > > > > > signalling set-up message as the probe packet > (eg > > > > > > > > RSVP PATH). > > > > > > > > > > > > > > > > > > > > o The PCN-marking behaviour is such that every > > > > > packet is > > > > > > > > > > PCN-marked > > > > > > > > > > if the flow should be blocked, hence only > > > a single > > > > > > > > > > probing packet > > > > > > > > > > is needed. > > > > > > > > > > > > > > > > > > > > I think the first of these bullets breaks > > > Assumption 3 > > > > > > > > > > (aggregation) and hence means that this viewpoint is > out > > > > > > > > of scope of > > > > > > > > > > the initial Charter of the PCN WG. > > > > > > > > > > > > > > > > > > > > phil > > > > > > > > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > > Steven Blake > > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 11:00:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJst1-0004cQ-Jz; Tue, 29 Jan 2008 11:00:35 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJst0-0004YR-Sm for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 11:00:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJst0-0004YJ-J1 for pcn@ietf.org; Tue, 29 Jan 2008 11:00:34 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJssy-0003LP-JH for pcn@ietf.org; Tue, 29 Jan 2008 11:00:34 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 16:00:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Tue, 29 Jan 2008 16:00:02 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34507@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <479F24FA.50400@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: Achihd4uI/r5qeojQEq7QF0AKBjuiAACbfEw From: To: X-OriginalArrivalTime: 29 Jan 2008 16:00:31.0973 (UTC) FILETIME=[135CF150:01C86290] X-Spam-Score: -1.0 (-) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ok. the text in version 02 is quote from charter, but I see your point.=20 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. > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 29 January 2008 13:07 > To: Eardley,PL,Philip,CXR9 R > Cc: babiarz@nortel.com; pcn@ietf.org > Subject: Re: [PCN] Review of pcn-architecture-02 draft >=20 > Hi Phil, >=20 > philip.eardley@bt.com 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". > > >=20 > 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. >=20 > Regards, >=20 > Michael >=20 >=20 > > 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:babiarz@nortel.com] > > *Sent:* 01 January 2008 20:03 > > *To:* PCN IETF > > *Subject:* [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.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:babiarz@nortel.com > > > > Telephone:613-763-6098 > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > >=20 > -- > 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:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 11:28:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtK2-0005WI-AJ; Tue, 29 Jan 2008 11:28:30 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJtJz-0005W8-Go for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 11:28:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtJz-0005W0-6s for pcn@ietf.org; Tue, 29 Jan 2008 11:28:27 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJtJy-0003ya-PG for pcn@ietf.org; Tue, 29 Jan 2008 11:28:27 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m0TGSAvI017860; Tue, 29 Jan 2008 10:28:10 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 10:28:10 -0600 Received: from [147.117.169.126] ([147.117.169.126]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 10:28:09 -0600 Subject: RE: [PCN] Questions on probing From: Steven Blake To: Georgios Karagiannis In-Reply-To: <001101c86254$f4bfe210$810c5982@dynamic.ewi.utwente.nl> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> <1201538832.3579.22.camel@neutrino> <001101c86254$f4bfe210$810c5982@dynamic.ewi.utwente.nl> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 29 Jan 2008 11:28:09 -0500 Message-Id: <1201624089.3012.17.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2008 16:28:09.0673 (UTC) FILETIME=[EF6DE390:01C86293] X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Tue, 2008-01-29 at 09:57 +0100, Georgios Karagiannis wrote: > Hi Steven > > According to the email discussion, I expect that Phil will update the text > in Section 7.3 > such that the feature that provides admission control when probing is used > is not considered > to be out of the scope of the PCN activities. > > Regarding your following comment: > > - we *will not* start any protocol work on probing. > > Your question in the original "Questions on probing" email was: > > 3. Does the working group need to do protocol work on probing prior to > > last call for the architecture draft? > > Therefore, I assume that your above observation should be: > - we *will not* start any protocol work on probing prior to > last call for the architecture draft You sir are correct. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 11:35:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtQy-0003xr-FV; Tue, 29 Jan 2008 11:35:40 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJtQx-0003xI-KO for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 11:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtQx-0003vn-8V for pcn@ietf.org; Tue, 29 Jan 2008 11:35:39 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJtQu-00048y-Nn for pcn@ietf.org; Tue, 29 Jan 2008 11:35:39 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 16:35:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Tue, 29 Jan 2008 16:35:23 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34508@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CB7E137@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gMMqJrgARhW3tABQYgmYAARTudA From: To: , X-OriginalArrivalTime: 29 Jan 2008 16:35:27.0262 (UTC) FILETIME=[F440ABE0:01C86294] X-Spam-Score: -1.0 (-) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org 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).=20 thanks phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 29 January 2008 08:18 > To: babiarz@nortel.com > Cc: pcn@ietf.org > Subject: AW: [PCN] Review of pcn-architecture-02 draft >=20 > Joe, >=20 > my response to two of your comments in line (further down). >=20 > Where I'm not commenting I accept or agree with your > response. >=20 > Regards, >=20 > Ruediger >=20 > | -----Urspr=FCngliche Nachricht----- > | Von: Jozef Babiarz [mailto:babiarz@nortel.com] > | Gesendet: Montag, 28. Januar 2008 17:42 > | An: Geib, R=FCdiger; pcn@ietf.org > | Betreff: RE: [PCN] Review of pcn-architecture-02 draft > | > | Ruediger, see comments below. > | > | Regards, Joe > | email:babiarz@nortel.com > | Telephone:613-763-6098 > | > | -----Original Message----- > | From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | Sent: January 17, 2008 5:34 AM > | To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org > | 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)." >=20 > * > [RG] Allright with me. > * >=20 > | ------- > | > | 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. > | >=20 > * > [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. >=20 > End of my comments in this mail > * >=20 > | --------- > | > | 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:babiarz@nortel.com] > | 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 > | | 2-jb.doc> > | > | > | > | = http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf > | | 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:babiarz@nortel.com > | > | Telephone:613-763-6098 > | > | >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 29 11:36:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtS7-0005YD-Gt; Tue, 29 Jan 2008 11:36:51 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JJtS5-0005Y8-UT for pcn-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 11:36:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtS5-0005Y0-Jx for pcn@ietf.org; Tue, 29 Jan 2008 11:36:49 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJtS5-0007co-99 for pcn@ietf.org; Tue, 29 Jan 2008 11:36:49 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0TGasgW032380; Tue, 29 Jan 2008 10:37:36 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 18:36:25 +0200 Received: from esdhcp03578.research.nokia.com ([172.21.35.78]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 18:36:25 +0200 Message-Id: From: Lars Eggert To: ext Georgios Karagiannis , Steve Blake , PCN IETF In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PCN] Questions on probing Date: Tue, 29 Jan 2008 18:36:23 +0200 References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Jan 2008 16:36:25.0357 (UTC) FILETIME=[16E143D0:01C86295] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On 2008-1-29, at 16:43, ext pcn-bounces@ietf.org wrote: > Section 11 is a new section called something like "Beyond the scope of > the initial charter" (suggested by steven blake) I think this would be better moved to an appendix, with a crystal clear indication that it discusses possibilities only. I'd also like to caution the WG that steady progress on the current milestones is essential - effort spent on out-of-charter items is unlikely to advance those. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 02:26:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7LM-0007tu-Tp; Wed, 30 Jan 2008 02:26:48 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JK7LK-0007qK-Cd for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 02:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7LJ-0007pA-Vd for pcn@ietf.org; Wed, 30 Jan 2008 02:26:46 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK7LI-0001MZ-5m for pcn@ietf.org; Wed, 30 Jan 2008 02:26:45 -0500 Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Wed, 30 Jan 2008 08:26:39 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jan 2008 08:26:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture draft- bi-directional flows Date: Wed, 30 Jan 2008 08:27:15 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CB7E538@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34504@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: AchfX9C1CRKalIWVQRSqH1x2AYFUawDIf8FQACO+DyA= References: <41A904C3-1335-42EF-B787-3CD5DA475E59@nokia.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B34504@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: , , X-OriginalArrivalTime: 30 Jan 2008 07:26:38.0806 (UTC) FILETIME=[73C6C760:01C86311] X-Spam-Score: -1.0 (-) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, certainly enough for admission control. A statement on termination=20 should be added too, because pre-conditions don't apply then. I'm=20 sorry not to be able to propose a statement, as for the time=20 being I'm not interested in termination as a required=20 functionality. Regards, Ruediger=20 | -----Original Message----- | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 | Sent: Tuesday, January 29, 2008 3:21 PM | To: lars.eggert@nokia.com; babiarz@nortel.com | Cc: pcn@ietf.org | Subject: RE: [PCN] Architecture draft- bi-directional flows |=20 | Note, bi-directional flows are discussed in the arch draft already. | Section 6, | http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#page -24 says=20 |=20 | o Bi-Directional Sessions: Many applications have bi-directional | sessions - hence there are two flows that should be admitted (or | terminated) as a pair - for instance a bi-directional voice call | only makes sense if flows in both directions are admitted. | However, PCN's mechanisms concern admission and termination of a | single flow, and coordination of the decision for both flows is a | matter for the signalling protocol and out of scope of PCN. One | possible example would use SIP pre-conditions; there are others. |=20 | Hopefully this is enough? |=20 | > -----Original Message----- | > From: Lars Eggert [mailto:lars.eggert@nokia.com] | > Sent: 25 January 2008 14:37 | > To: ext Jozef Babiarz | > Cc: PCN IETF | > Subject: Re: [PCN] Architecture draft- bi-directional flows | >=20 | > Hi, | >=20 | > On 2007-12-17, at 16:58, ext Jozef Babiarz wrote: | >> I believe that the PCN Architecture draft needs to discuss and = explain | >> how admission control and flow termination works at high level for=20 | >> telephony and video conferencing applications and that both, = telephony | >> and video conferencing applications have bi-directional flows. For=20 | >> admission control a new flow can not be admitted unless the traffic = | >> level on both unidirectional paths is below the PCN-lower-rate. As=20 | >> well for flow termination, a bi-directional flow is terminated if=20 | >> one of the unidirectional paths is in excess of PCN-upper-rate. | >=20 | > can you elaborate a bit why something more is needed than simply=20 | > setting up both directions independently, and failing if that = didn't=20 | > work? Or, for termination, when the app realizes that one direction=20 | > got torn down, it tears down the other direction? | >=20 | > Lars | >=20 | >=20 | > _______________________________________________ | > PCN mailing list | > PCN@ietf.org | > https://www1.ietf.org/mailman/listinfo/pcn |=20 |=20 | _______________________________________________ | PCN mailing list | PCN@ietf.org | https://www1.ietf.org/mailman/listinfo/pcn |=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 02:40:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7Yz-0004Th-Fq; Wed, 30 Jan 2008 02:40:53 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JK7Yy-0004Ta-4Q for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 02:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7Yx-0004TS-NH for pcn@ietf.org; Wed, 30 Jan 2008 02:40:51 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK7Yw-0001b7-3K for pcn@ietf.org; Wed, 30 Jan 2008 02:40:51 -0500 Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Wed, 30 Jan 2008 08:40:45 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jan 2008 08:40:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Questions on probing Date: Wed, 30 Jan 2008 08:41:22 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CB7E543@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFAAI7tcsA== References: <001101c86254$f4bfe210$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34505@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Jan 2008 07:40:45.0061 (UTC) FILETIME=[6C2F0B50:01C86313] X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, | Referring to the scenario where the PCN-domain reaches out to=20 | the end terminals. Link capacity is likely to be low at the=20 | edge of the PCN-domain. This breaks Assumption 3=20 | (aggregation) and hence further consideration is out of scope=20 | of the initial Charter of the PCN WG. I'm a bit puzzled here - so far probing was suggested to cope=20 with an absence of flows on an ingress egress aggregate, but=20 in my recollection of the discussion assumption 3 was holding=20 between edge nodes. While I agree that it may be useful to=20 see marked packets travelling further then PCN edge nodes,=20 I don't see a point in discussing measurement based=20 admission control on links where it doesn't work (that's=20 the meaning of "assumption 3 doesn't hold"). Regards, Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 04:15:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK92J-0003Ea-HJ; Wed, 30 Jan 2008 04:15:15 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JK92H-0003ET-Jo for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 04:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK92H-0003EL-A9 for pcn@ietf.org; Wed, 30 Jan 2008 04:15:13 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK92F-0003N1-Gs for pcn@ietf.org; Wed, 30 Jan 2008 04:15:13 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 09:15:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture draft- bi-directional flows Date: Wed, 30 Jan 2008 09:15:09 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3450B@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CB7E538@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: AchfX9C1CRKalIWVQRSqH1x2AYFUawDIf8FQACO+DyAAA+b2sA== From: To: , , X-OriginalArrivalTime: 30 Jan 2008 09:15:10.0324 (UTC) FILETIME=[9CF19340:01C86320] X-Spam-Score: -1.0 (-) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ok, I'll leave the text as it is. it mentions flow termination and I think the level of detail is sufficient. Thanks phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 30 January 2008 07:27 > To: Eardley,PL,Philip,CXR9 R; lars.eggert@nokia.com; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Architecture draft- bi-directional flows >=20 > Phil, >=20 > certainly enough for admission control. A statement on termination > should be added too, because pre-conditions don't apply then. I'm > sorry not to be able to propose a statement, as for the time > being I'm not interested in termination as a required > functionality. >=20 > Regards, >=20 > Ruediger >=20 > | -----Original Message----- > | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > | Sent: Tuesday, January 29, 2008 3:21 PM > | To: lars.eggert@nokia.com; babiarz@nortel.com > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Architecture draft- bi-directional flows > | > | Note, bi-directional flows are discussed in the arch draft already. > | Section 6, > | http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#page > -24 says > | > | o Bi-Directional Sessions: Many applications have bi-directional > | sessions - hence there are two flows that should be admitted (or > | terminated) as a pair - for instance a bi-directional voice call > | only makes sense if flows in both directions are admitted. > | However, PCN's mechanisms concern admission and termination of a > | single flow, and coordination of the decision for both flows is a > | matter for the signalling protocol and out of scope of PCN. One > | possible example would use SIP pre-conditions; there are others. > | > | Hopefully this is enough? > | > | > -----Original Message----- > | > From: Lars Eggert [mailto:lars.eggert@nokia.com] > | > Sent: 25 January 2008 14:37 > | > To: ext Jozef Babiarz > | > Cc: PCN IETF > | > Subject: Re: [PCN] Architecture draft- bi-directional flows > | > > | > Hi, > | > > | > On 2007-12-17, at 16:58, ext Jozef Babiarz wrote: > | >> I believe that the PCN Architecture draft needs to discuss and > explain > | >> how admission control and flow termination works at high level for > | >> telephony and video conferencing applications and that both, > telephony > | >> and video conferencing applications have bi-directional flows. For > | >> admission control a new flow can not be admitted unless the traffic > | >> level on both unidirectional paths is below the PCN-lower-rate. As > | >> well for flow termination, a bi-directional flow is terminated if > | >> one of the unidirectional paths is in excess of PCN-upper-rate. > | > > | > can you elaborate a bit why something more is needed than simply > | > setting up both directions independently, and failing if that didn't > | > work? Or, for termination, when the app realizes that one direction > | > got torn down, it tears down the other direction? > | > > | > Lars > | > > | > > | > _______________________________________________ > | > PCN mailing list > | > PCN@ietf.org > | > https://www1.ietf.org/mailman/listinfo/pcn > | > | > | _______________________________________________ > | PCN mailing list > | PCN@ietf.org > | https://www1.ietf.org/mailman/listinfo/pcn > | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 06:49:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKBRq-0007kg-9T; Wed, 30 Jan 2008 06:49:46 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKBRo-0007kQ-8u for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 06:49:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKBRn-0007kI-SY for pcn@ietf.org; Wed, 30 Jan 2008 06:49:43 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKBRn-0001Cm-AU for pcn@ietf.org; Wed, 30 Jan 2008 06:49:43 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 11:49:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jan 2008 11:49:40 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3450F@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Architecture draft - PCN & ECN Thread-Index: AchjNjLVsP7br8sBRBqziF4Z6vluYA== From: To: X-OriginalArrivalTime: 30 Jan 2008 11:49:41.0824 (UTC) FILETIME=[33303400:01C86336] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Subject: [PCN] Architecture draft - PCN & ECN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999919283==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1999919283== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86336.329AB99D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86336.329AB99D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently updating the architecture draft to reflect comments received. =20 In Section 3.5,other assumptions, currently says: The following two assumptions apply if the PCN WG decides to encode PCN-marking in the ECN-field. =20 o It is assumed that PCN-nodes do not perform ECN, [RFC3168], on PCN-packets. =20 o If a packet that is part of a PCN-flow arrives at a PCN-ingress- node with its CE (Congestion experienced) codepoint set, then we assume that the PCN-ingress-node drops the packet. After its initial Charter is complete, the WG may decide to work on a mechanism (such as through a signalling extension) that enables ECN-marking to be carried transparently across the PCN-domain. =20 There was some unresolved discussion about the 2nd bullet (downgrading to best effort class was mentioned as another possibility), and more generally the relationship of ECN & PCN. the issue also depends heavily on the PCN encoding issue - I believe an update of that draft is about to appear (today??) =20 So I'm proposing to replace the second bullet: o If a packet that is part of a PCN-flow arrives at a PCN-ingress- node with its CE (Congestion experienced) codepoint set, then a number of possibilities have been mentioned. The PCN-ingress-node could drop the packet, or downgrade it to best effort, or it could encapsulate the packet. Encapsulation would enable the ECN-marking to be carried transparently across the PCN-domain, but may require an additional mechanism (such as a signalling extension). =20 Hopefully the issue will get more discussion, but I think that's best done in the context of the encoding draft. =20 phil=20 =20 =20 =20 ------_=_NextPart_001_01C86336.329AB99D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Currently updating the architecture draft to = reflect comments received.

 

In Section 3.5,other assumptions, currently = says:

The following two assumptions apply if the =
PCN WG decides to encode
   PCN-marking in the =
ECN-field.
 
   o  It is assumed that =
PCN-nodes do not perform ECN, [RFC3168], =
on
      =
PCN-packets.
 
   o  If a packet that is part =
of a PCN-flow arrives at a PCN-ingress-
      node with its =
CE (Congestion experienced) codepoint set, then =
we
      assume that =
the PCN-ingress-node drops the packet.  After =
its
      initial =
Charter is complete, the WG may decide to work on =
a
      mechanism =
(such as through a signalling extension) that =
enables
      ECN-marking to =
be carried transparently across the =
PCN-domain.
 
There was =
some unresolved discussion about the 2nd bullet (downgrading =
to best effort class was mentioned as another possibility), and more =
generally the relationship of ECN & PCN. the issue also depends =
heavily on the PCN encoding issue - I believe an update of that draft is =
about to appear (today??)
 
So =
I’m proposing to replace the second =
bullet:
   o  If a packet that is part =
of a PCN-flow arrives at a PCN-ingress-
      node with its =
CE (Congestion experienced) codepoint set, then a number of =
possibilities have been mentioned. The PCN-ingress-node could drop the =
packet, or downgrade it to best effort, or it could encapsulate the =
packet. Encapsulation would enable the ECN-marking to be carried =
transparently across the PCN-domain, but may require an additional =
mechanism (such as a signalling =
extension).
 
Hopefully =
the issue will get more discussion, but I think that’s best done =
in the context of the encoding draft.
 
phil =

 

 

 

=00 ------_=_NextPart_001_01C86336.329AB99D-- --===============1999919283== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1999919283==-- From pcn-bounces@ietf.org Wed Jan 30 07:41:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCFY-0007Mx-7o; Wed, 30 Jan 2008 07:41:08 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKCFW-0007Ek-Pq for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 07:41:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCFW-0007DY-EP for pcn@ietf.org; Wed, 30 Jan 2008 07:41:06 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKCFV-0002lS-Ak for pcn@ietf.org; Wed, 30 Jan 2008 07:41:06 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 12:41:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] A two-layer approach for PCN Date: Wed, 30 Jan 2008 12:41:02 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34513@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <475F09D2.9030804@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A two-layer approach for PCN Thread-Index: Acg8QdmkdRhCyIpFTm+Zy4WTlHsaMgm+fZxQ From: To: , X-OriginalArrivalTime: 30 Jan 2008 12:41:03.0880 (UTC) FILETIME=[603CA080:01C8633D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, To take account of this, I think the best thing is to add a boost near the start of Section 4 (high level functional archit), on the lines: The objective is to standardise PCN-marking behaviour, but potentially produce more than one (informational) RFC describing how PCN-boundary-nodes react to PCN-marks.=20 I'll also add some words on similar lines to S8.1 (Configuration OAM) phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 11 December 2007 22:06 > To: pcn > Subject: [PCN] A two-layer approach for PCN >=20 > Hi all, >=20 > during last week's meeting I had discussions with many people regarding > a separation of packet marking vs. admission control and flow > termination aspects. The intention was to make the structure of PCN more > obvious and to facilitate its adaptation to various network > architectures. The following text reflects the outcome of these > discussions. >=20 > Comments are welcome. >=20 > Regards, >=20 > Michael >=20 > -- >=20 > The pre-congestion notification (PCN) architecture consists of two > different layers: the packet marking layer (PML) and the admission > control and flow termination layer (ACFTL). > The packet marking layer (PML) describes how PCN-capable interior nodes > meter and mark PCN packets. Within a single network only one packet > marking layer (PML) MUST be deployed, i.e. PCN-capable interior nodes > MUST implement the same metering and marking behavior for all links. The > admission control and flow termination layer (ACFTL) describes how PCN > edge nodes make use of the packet markings observed by the PCN egress > node to decide whether new flows can be accepted or whether already > admitted flows need to be terminated. The implementation of the > admission control and flow termination layer (ACFTL) may take advantage > of specific transport architectures and may be tailored for various > signaling architectures with which it needs to interoperate. In contrast > to the packet marking layer (PML), different instances admission control > and flow termination layers (ACFTL) MAY be used in the same network as > long as they interpret the semantics of the packet markings in the same > way and don't lead to unfairness issues. >=20 >=20 > +---+---+---+---+ > | A | A | . | A | > | C | C | . | C | > | F | F | . | F | > | T | T | . | T | > | L | L | . | L | > | | | | | > | 0 | 1 | . | n | > +---+---+---+---+ > | PML | > +---------------+ >=20 > Figure 1: Within a single network, only one packet marking layer (PML) > MUST be deployed, but several admission control and flow > termination layers (ACFTL) MAY coexist. >=20 > In the following, the concepts of the packet marking layer (PML) and > admission control and flow termination layer (ACFTL) are briefly > illustrated. >=20 > 4 examples of mutually exclusive interior node behaviors for > implementation of the PML: >=20 > a) Ramp marking based on the admissible rate and excess-rate marking > based on the supportable rate (CL proposal) > b) Threshold marking based on the admissible rate and excess-rate > marking with marking frequency reduction based on the supportable rate > (3sm proposal) > c) Threshold marking based on the admissible rate and excess-rate > marking based on the supportable rate (behavioral intersection of CL and > 3sm proposal) > d) Excess rate marking based on the admissible rate (Single Marking > proposal) >=20 > Note that only one packet marking layer (PML) can be deployed within a > single network. >=20 >=20 > 3 examples for different edge node behaviors for implementation of the > admission control and flow termination layer (ACFTL) based on the packet > marking layer b) above: >=20 > o E3Tunnel > Given: edge-to-edge MPLS tunnels; > Egress node measures CLE for tunnel and depending on that value, it > sends an "admission-stop" or "admission-continue" message to the > corresponding ingress node that then stops or continues admitting > further flows. > Flows are terminated when one of its packets was ET-marked. > o End2PS > Given: end-to-end on-path signalling protocol; > PCN egress node is a RSVP capable node and returns PATHERR if first > PATH msg was "admission-stop" marked; PCN ingress node accepts all flows > whose RESV messages come through. > Flows are terminated when one of its packets was ET-marked: the PCN > egress node sends a RESVTEAR message to the PCN ingress. > o Centralized node > Given: centralized node (CN) in charge of admitting or terminating > flows; > Upon a new flow arrival, the CN issues an admission request to PCN > ingress node for a future data flow with an indicated source-destination > tuple; > CN sends a probe packet to the PCN egress node which returns the > probe to the CN; the CN rejects the flow if probe was marked and admits > it if probe was unmarked. > Flows are terminated when one of its packets was ET-marked. The PCN > egress node sends the marked packet to the CN which terminated the > corresponding flow. >=20 > These admission control and flow termination layers (ACFTL) MAY > simultaneously be applied in the same network. Similar methods can be > defined based on the other packet marking layers (PML) defined above. >=20 > Within the current charter, only one packet marking layer (PML) should > be standardized as well as only one admission control and flow > termination layer (ACFTL), presumably for ingress-egress aggregates. > However, it is desirable that the architecture is extensible towards > other admission control and flow termination layers (ACFTL) to address > the need of various network architectures (e.g., without explicit > aggregates, with multipath routing, with centralized control nodes, ...) > that need QoS support in the future. >=20 > Note: this text does not contradict the current version of the > architecture draft. Essentially, the packet marking behavior of interior > nodes is put into a packet marking layer and the admission control and > flow termination behavior of edge nodes is put into an admission control > and flow termination layer. The two-layer approach just makes the idea > more explicit that different edge node behaviors may be defined for a > single interior node behavior and that several edge node behaviors may > coexist in the same network if necessary. >=20 > -- > 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:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 08:03:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCbK-0006ZD-AX; Wed, 30 Jan 2008 08:03:38 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKCbJ-0006Sv-HQ for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 08:03:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCbJ-0006On-5l for pcn@ietf.org; Wed, 30 Jan 2008 08:03:37 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKCbI-0003c2-Ha for pcn@ietf.org; Wed, 30 Jan 2008 08:03:36 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 13:03:35 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Questions on probing Date: Wed, 30 Jan 2008 13:03:34 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34514@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CB7E543@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFAAI7tcsAADTIuQ From: To: X-OriginalArrivalTime: 30 Jan 2008 13:03:35.0175 (UTC) FILETIME=[85ABE170:01C86340] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, Not sure I exactly get what point is puzzling.=20 But to clarify: [quoting from Arch draft] "3.3. Assumption 3: Many flows and additional load We assume that there are many flows on any bottleneck link in the PCN-domain ... We do not make explicit assumptions on how many PCN-flows are in each ingress-egress-aggregate." And on the reasons for probing: "7.3. Discussion of rationale for probing, its downsides and open issues It is an unresolved question whether probing is really needed, but three viewpoints have been put forward as to why it is useful. The first is perhaps the most obvious: there is no PCN-traffic on the ingress-egress-aggregate. The second assumes that multipath routing ECMP is running in the PCN-domain. The third viewpoint is that admission control is always done by probing." > | (aggregation) and hence further consideration is out of scope > | of the initial Charter of the PCN WG. Mention of Charter scope will be moved to Appendix. > I don't see a point in discussing measurement based > admission control on links where it doesn't work (that's > the meaning of "assumption 3 doesn't hold"). I agree with that! Thanks, phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 30 January 2008 07:41 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Questions on probing >=20 > Phil, >=20 > | Referring to the scenario where the PCN-domain reaches out to > | the end terminals. Link capacity is likely to be low at the > | edge of the PCN-domain. This breaks Assumption 3 > | (aggregation) and hence further consideration is out of scope > | of the initial Charter of the PCN WG. >=20 > I'm a bit puzzled here - so far probing was suggested to cope > with an absence of flows on an ingress egress aggregate, but > in my recollection of the discussion assumption 3 was holding > between edge nodes. While I agree that it may be useful to > see marked packets travelling further then PCN edge nodes, > I don't see a point in discussing measurement based > admission control on links where it doesn't work (that's > the meaning of "assumption 3 doesn't hold"). >=20 > Regards, >=20 > Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 08:12:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCk0-000320-OT; Wed, 30 Jan 2008 08:12:36 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKCk0-00031v-Ck for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 08:12:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKCk0-00031n-1N for pcn@ietf.org; Wed, 30 Jan 2008 08:12:36 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKCjz-0003vo-CX for pcn@ietf.org; Wed, 30 Jan 2008 08:12:35 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Wed, 30 Jan 2008 14:12:32 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jan 2008 14:12:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Questions on probing Date: Wed, 30 Jan 2008 14:13:09 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CB7E783@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34514@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing Thread-Index: AchhzmQQvc8cTAVESoOwFTSlGjj1cwAhW/CQAAvcdFAAI7tcsAADTIuQAAhspvA= References: <1B6169C658325341A3B8066E23919E1CB7E543@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34514@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Jan 2008 13:12:31.0848 (UTC) FILETIME=[C58DAE80:01C86341] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, your first statement reads: "Link capacity is likely to be low at the edge=20 of the PCN-domain. This breaks Assumption 3 (aggregation) and hence further consideration=20 is out of scope of the initial Charter of=20 the PCN WG." My statement is: in the case that Assumption 3=20 doesn't hold on a link, measurement based=20 admission control and probing don't make sense.=20 This issue should never appear on any charter. Regards, Ruediger=20 | -----Original Message----- | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 | Sent: Wednesday, January 30, 2008 2:04 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Questions on probing |=20 | Hi, |=20 | Not sure I exactly get what point is puzzling.=20 |=20 | But to clarify: [quoting from Arch draft] |=20 | "3.3. Assumption 3: Many flows and additional load We assume=20 | that there are many flows on any bottleneck link in the | PCN-domain ... | We do not make explicit assumptions on how many PCN-flows are in each | ingress-egress-aggregate." |=20 | And on the reasons for probing: |=20 | "7.3. Discussion of rationale for probing, its downsides and=20 | open issues | It is an unresolved question whether probing is really needed, but | three viewpoints have been put forward as to why it is useful. The | first is perhaps the most obvious: there is no PCN-traffic on the | ingress-egress-aggregate. The second assumes that multipath routing | ECMP is running in the PCN-domain. The third viewpoint is that | admission control is always done by probing." |=20 | > | (aggregation) and hence further consideration is out of scope of = the=20 | > | initial Charter of the PCN WG. | Mention of Charter scope will be moved to Appendix. |=20 | > I don't see a point in discussing measurement based admission = control=20 | > on links where it doesn't work (that's the meaning of "assumption 3=20 | > doesn't hold"). |=20 | I agree with that! |=20 | Thanks, | phil |=20 | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: 30 January 2008 07:41 | > To: Eardley,PL,Philip,CXR9 R | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Questions on probing | >=20 | > Phil, | >=20 | > | Referring to the scenario where the PCN-domain reaches out to the=20 | > | end terminals. Link capacity is likely to be low at the edge of = the=20 | > | PCN-domain. This breaks Assumption 3 | > | (aggregation) and hence further consideration is out of scope of = the=20 | > | initial Charter of the PCN WG. | >=20 | > I'm a bit puzzled here - so far probing was suggested to cope with = an=20 | > absence of flows on an ingress egress aggregate, but in my=20 | > recollection of the discussion assumption 3 was holding between edge = | > nodes. While I agree that it may be useful to see marked packets=20 | > travelling further then PCN edge nodes, I don't see a point in=20 | > discussing measurement based admission control on links where it=20 | > doesn't work (that's the meaning of "assumption 3 doesn't hold"). | >=20 | > Regards, | >=20 | > Ruediger |=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 30 13:36:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHne-0000nt-J7; Wed, 30 Jan 2008 13:36:42 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKHnc-0000my-Sw for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHnc-0000me-IE for pcn@ietf.org; Wed, 30 Jan 2008 13:36:40 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHnX-0006K8-E9 for pcn@ietf.org; Wed, 30 Jan 2008 13:36:40 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 18:36:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Wed, 30 Jan 2008 18:36:33 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3451A@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gWu9Q6w From: To: X-OriginalArrivalTime: 30 Jan 2008 18:36:34.0368 (UTC) FILETIME=[0A32CC00:01C8636F] X-Spam-Score: -1.0 (-) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1628391189==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1628391189== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8636F.09C40E7B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8636F.09C40E7B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Follow-up on one specific point. =20 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.=20 =20 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. =20 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). =20 (*) =3D (terminology assumes virtual queue implementation of pcn marking behaviour!) =20 thanks, phil =20 =20 =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C8636F.09C40E7B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft

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).

 

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

 

thanks,

phil

 

 

 

-----Original Message-----
From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [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.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:babiarz@nortel.com

Telephone:613-763-6098

=00 ------_=_NextPart_001_01C8636F.09C40E7B-- --===============1628391189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1628391189==-- From pcn-bounces@ietf.org Wed Jan 30 13:45:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHw1-0004xK-6l; Wed, 30 Jan 2008 13:45:21 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKHvz-0004vX-TU for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHvz-0004ui-JC for pcn@ietf.org; Wed, 30 Jan 2008 13:45:19 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHvv-0006XB-0b for pcn@ietf.org; Wed, 30 Jan 2008 13:45:19 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 18:45:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Wed, 30 Jan 2008 18:45:13 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3451C@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gWr7SMw From: To: , X-OriginalArrivalTime: 30 Jan 2008 18:45:13.0859 (UTC) FILETIME=[3FD6D530:01C86370] X-Spam-Score: -1.0 (-) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0988861280==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0988861280== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86370.3F5844EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86370.3F5844EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe =20 You make some comments on Section 5.7 Tunnelling, which I didn't really understand. =20 After=20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes. =20 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 ) 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.=20 =20 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.=20 =20 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).=20 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. =20 Thanks, phil =20 =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C86370.3F5844EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft

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) 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:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [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.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:babiarz@nortel.com

Telephone:613-763-6098

=00 ------_=_NextPart_001_01C86370.3F5844EC-- --===============0988861280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0988861280==-- From pcn-bounces@ietf.org Wed Jan 30 13:55:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKI6F-000079-LN; Wed, 30 Jan 2008 13:55:55 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKI6E-00006C-T0 for pcn-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKI6E-000064-J8 for pcn@ietf.org; Wed, 30 Jan 2008 13:55:54 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKI67-0006lq-G0 for pcn@ietf.org; Wed, 30 Jan 2008 13:55:54 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 18:55:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Wed, 30 Jan 2008 18:55:45 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3451D@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gWfQvTg From: To: , X-OriginalArrivalTime: 30 Jan 2008 18:55:46.0273 (UTC) FILETIME=[B8C98D10:01C86371] X-Spam-Score: -1.0 (-) X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1660333083==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1660333083== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86371.B84208EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86371.B84208EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe =20 Final follow-up to your review, capturing a few odd points that didn't seem worth a separate thread.=20 Thanks for the careful review! phil =20 1. In S1, about the bullet=20 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. =20 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.=20 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.=20 =20 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) =20 3. I ignored your comment in S3.5. it's true, but the term PCN-packets already includes the idea of PCN traffic classes.=20 =20 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.=20 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.=20 =20 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). =20 Thanks phil =20 =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C86371.B84208EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft

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:babiarz@nortel.com]
Sent: 01 January 2008 20:03
To: PCN IETF
Subject: [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.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:babiarz@nortel.com

Telephone:613-763-6098

=00 ------_=_NextPart_001_01C86371.B84208EB-- --===============1660333083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1660333083==-- From pcn-bounces@ietf.org Thu Jan 31 02:29:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKTrO-0004Zq-SS; Thu, 31 Jan 2008 02:29:22 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKTrN-0004ZY-AN for pcn-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 02:29:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKTrM-0004ZP-Px for pcn@ietf.org; Thu, 31 Jan 2008 02:29:20 -0500 Received: from tcmail12.telekom.de ([217.5.214.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKTrL-0007uE-Ga for pcn@ietf.org; Thu, 31 Jan 2008 02:29:20 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 31 Jan 2008 08:29:17 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 08:29:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Thu, 31 Jan 2008 08:29:54 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CB7E936@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3451A@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gWu9Q6wABtqk/A= References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B3451A@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 31 Jan 2008 07:29:16.0676 (UTC) FILETIME=[FC499440:01C863DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0062532318==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0062532318== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C863DA.FBF9D1FD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C863DA.FBF9D1FD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, =20 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. =20 Regards, =20 Ruediger ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, January 30, 2008 7:37 PM To: pcn@ietf.org Subject: RE: [PCN] Review of pcn-architecture-02 draft =09 =09 Hi, Follow-up on one specific point. =20 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.=20 =20 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. =20 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). =20 (*) =3D (terminology assumes virtual queue implementation of pcn = marking behaviour!) =20 thanks, phil =20 =20 =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C863DA.FBF9D1FD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft
Phil,
 
while I'm not favouring a situation where non = PCN=20 traffic shares queues with PCN traffic I think that you are right. If = this=20 happens and the non PCN traffic has higher priority, it must be = accounted for=20 PCN.
 
Regards,
 
Ruediger

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, January 30, = 2008=20 7:37 PM
To: pcn@ietf.org
Subject: RE: [PCN] Review = of=20 pcn-architecture-02 draft

Hi,

Follow-up = on one=20 specific point.

 

In S4.5, = where it=20 says:

There may = be traffic=20 that is more important than PCN, perhaps a particular application or = an=20 operator's control messages. A PCN-node may dedicate capacity to such = traffic=20 or priority schedule it over PCN. In the latter case its traffic needs = to=20 contribute to the PCN meters.

You deleted = the final=20 sentence.

 

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

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

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

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

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

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

 

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

 

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

 

thanks,

phil

 

 

 

-----Original=20 Message-----
From: = Jozef=20 Babiarz [mailto:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [PCN] Review of=20 pcn-architecture-02 draft

 

Hi Phil,

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

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

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.= doc=20

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.= pdf=20

Changes of note:

- On terminology, changed PCN-boundary-node = to=20 PCN-edge-node.

- Made several changes in Section 5.2, 5.3, = 5.4 and=20 5.5.

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

- Most of the other changes through out the = draft are=20 editorial.

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

Happy New = Year!

Regards,=20 Joe

email:babiarz@nortel.com

Telephone:613-763-6098

<= /BODY> ------_=_NextPart_001_01C863DA.FBF9D1FD-- --===============0062532318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0062532318==-- From pcn-bounces@ietf.org Thu Jan 31 03:35:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUtj-0000rj-JX; Thu, 31 Jan 2008 03:35:51 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1JKUti-0000rU-G5 for pcn-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 03:35:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUti-0000rH-0g for pcn@ietf.org; Thu, 31 Jan 2008 03:35:50 -0500 Received: from tcmail12.telekom.de ([217.5.214.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKUtg-0000mZ-Fd for pcn@ietf.org; Thu, 31 Jan 2008 03:35:49 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 31 Jan 2008 09:35:47 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jan 2008 09:35:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Review of pcn-architecture-02 draft Date: Thu, 31 Jan 2008 09:36:23 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CB7E9A1@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3451C@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Review of pcn-architecture-02 draft Thread-Index: AchMsUVMJpNiBa6oSdGoOp9d/8/e0gWr7SMwAB6IdPA= References: <9671A92C3C8B5744BC97F855F7CB646513C4D2D0@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA503B3451C@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 31 Jan 2008 08:35:46.0676 (UTC) FILETIME=[46834340:01C863E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0898783635==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0898783635== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C863E4.462532E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C863E4.462532E1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, =20 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: =20 - backbone transit using a carrier IP VPN service - a business access connected via L2TP over DSL =20 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. =20 This scenario should be supported, I support Joe's view. Picking up = Joe's drafted text, what about the following (my changes marked): =20 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. =20 Deletions are hard to mark, that's why I highlighted "PCN". =20 I think, the scenario is somewhat similar to passing a non PCN capable = node (without a tunnel) in a PCN domain. =20 Regards, Ruediger =20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, January 30, 2008 7:45 PM To: babiarz@nortel.com; pcn@ietf.org Subject: RE: [PCN] Review of pcn-architecture-02 draft =09 =09 Joe =20 You make some comments on Section 5.7 Tunnelling, which I didn't really = understand. =20 After=20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes. =20 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 = = ) 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.=20 =20 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.=20 =20 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).=20 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. =20 Thanks, phil =20 =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 01 January 2008 20:03 To: PCN IETF Subject: [PCN] Review of pcn-architecture-02 draft =20 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.=20 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.=20 - 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:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C863E4.462532E1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of pcn-architecture-02 draft
Phil,
 
if the PCN domain spans across an embedded = non PCN=20 domain, then the PCN marked packets may be tunneled without the outer = header=20 supporting PCN while the PCN marks of the inner header should be = left=20 unchanged. Examples are:
 
- backbone transit using a carrier IP = VPN=20 service
- a business access connected via L2TP over=20 DSL
 
In both cases the carrier providing = connectivity may=20 not support PCN, but the end point using that carrier connectivity = product may=20 be in a PCN domain. It is important that the tunnel starts and ends in = the same=20 PCN domain (which holds for the given examples). Once the charter allows = for=20 extended discussion, the tunnel may also connect two PCN=20 domains.
 
This scenario should be supported, I support = Joe's=20 view. Picking up Joe's drafted text, what about the following (my = changes=20 marked):
 

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

 

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

 

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

 
Regards, Ruediger
 

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, January 30, = 2008=20 7:45 PM
To: babiarz@nortel.com; = pcn@ietf.org
Subject: RE:=20 [PCN] Review of pcn-architecture-02 draft

Joe

 

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

 

After=20

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

   PCN-egress-nodes. =20

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) after all the other (PCN and tunnelling) =
functions.

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

 

You=20 added:

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

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

 

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

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

However:

In the case =931.  The tunnel starts = outside a=20 PCN-domain and finishes inside it.=94

You wrote:

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

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

 

Thanks,

phil

 

 

-----Original=20 Message-----
From: = Jozef=20 Babiarz [mailto:babiarz@nortel.com]
Sent: 01 January 2008 = 20:03
To: PCN IETF
Subject: [PCN] Review of=20 pcn-architecture-02 draft

 

Hi Phil,

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

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

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.= doc=20

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.= pdf=20

Changes of note:

- On terminology, changed PCN-boundary-node = to=20 PCN-edge-node.

- Made several changes in Section 5.2, 5.3, = 5.4 and=20 5.5.

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

- Most of the other changes through out the = draft are=20 editorial.

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

Happy New = Year!

Regards,=20 Joe

email:babiarz@nortel.com

Telephone:613-763-6098

<= /BODY> ------_=_NextPart_001_01C863E4.462532E1-- --===============0898783635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0898783635==--