RE: [PCN] Architecture draft - probing section & general updates.

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Thu, 25 October 2007 09:30 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz3A-0003x9-M3; Thu, 25 Oct 2007 05:30:48 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikz39-0003us-Jp for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:30:47 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz38-0003uj-Q1 for pcn@ietf.org; Thu, 25 Oct 2007 05:30:46 -0400
Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikz38-0000sX-0R for pcn@ietf.org; Thu, 25 Oct 2007 05:30:46 -0400
Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 11:30:36 +0200
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, 25 Oct 2007 11:30:06 +0200
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 - probing section & general updates.
Date: Thu, 25 Oct 2007 11:30:05 +0200
Message-Id: <1B6169C658325341A3B8066E23919E1C4C132A@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Architecture draft - probing section & general updates.
thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAASrNzAACRENBA=
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: babiarz@nortel.com
X-OriginalArrivalTime: 25 Oct 2007 09:30:06.0146 (UTC) FILETIME=[A0D36A20:01C816E9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Cc: pcn@ietf.org
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org

Joe,

if I understand you right, the PCN ingress/egress nodes are CPEs 
(or the like) connected to a single carriers network and this 
carrier supports PCN. Is that correct?

While there are many different accesses and a high number 
access to access communications, each single access carries 
aggregated traffic from some origins only (but not from all).

The accesses probably capture congestion information from WAN 
links close to them - the number of those usually is 
restricted and some of the already admitted flows pass them.
Without any congestion feedback/indication on ingress or egress
- admit the next flow. Otherwise, probing may be useful.

My own perception of PCN would be more carrier centric, assuming 
the PCN edge nodes to be part of the carrier network and not 
of the customers. But this doesn't necessary invalidate your 
example.

Regards,

Rudiger


|-----Original Message-----
|From: Jozef Babiarz [mailto:babiarz@nortel.com]
|Sent: Wednesday, October 24, 2007 6:14 PM
|To: Geib, Rudiger
|Cc: pcn@ietf.org
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|Ruediger, 
|I'm thinking of a scenario that many enterprises face today. 
|Large multi
|location enterprises use multiple WAN links or VPS to 
|interconnect their
|locations. PCN is run inside the enterprise network including WAN links
|which maybe tunneled across the carrier network. Network Access Control
|with PCN admission control is done at the enterprise access edge nodes.
|New flows can be routed to any egress access edge node and some flows
|will (between different locations) be routed over one of the WAN links
|which are normally bandwidth constrained. There is a high probability
|that many access nodes will only have one flow between each other as
|there are a large number of them.
|
|Regards, Joe
|email:babiarz@nortel.com
|Telephone:613-763-6098
|
|-----Original Message-----
|From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
|Sent: October 24, 2007 3:04 AM
|To: Babiarz, Jozef (CAR:0S03)
|Cc: pcn@ietf.org
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|Joe,
|
|my perception is, that probing may be useful, once there is 
|pre-congestion. In a situation without a single admitted 
|flow between an ingress and an egress, if neither ingress 
|node nor egress node have any indication of pre-congestion 
|on any of the links crossed by the PCN flows passing through 
|them, there's with high probability no need to probe, 
|I'd assume. I don't do simulations and would like to invite
|those simulating to come up with cases where this assumption 
|is wrong.
|
|I'd further propose to collect information from providers 
|on the probability of the event you describe. 
|
|Regards, 
|
|Rudiger
|
||-----Original Message-----
||From: Jozef Babiarz [mailto:babiarz@nortel.com]
||Sent: Tuesday, October 23, 2007 6:22 PM
||To: Geib, Rudiger; philip.eardley@bt.com
||Cc: pcn@ietf.org
||Subject: RE: [PCN] Architecture draft - probing section & general
||updates.
||
||
||Ruediger, the issue is not addition of one more flow into the 
|link that
||is experiencing (pre-)congestion level for admission but potentially
||hundreds of new ingress-egress aggregates that have not been 
||established
||passing through the link. 
||
||Regards, Joe
||email:babiarz@nortel.com
||Telephone:613-763-6098
||
||-----Original Message-----
||From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
||Sent: October 23, 2007 4:19 AM
||To: philip.eardley@bt.com
||Cc: pcn@ietf.org
||Subject: RE: [PCN] Architecture draft - probing section & general
||updates.
||
||Phil,
||
||I appreciate that probing is optional. I understand that to mean that
||standardisation allows to operate PCN within a domain without 
|having to
||support any probing functionality.
||
||There may be operational conditions, when probing makes 
|sense. This may
||be the case, if the number of multiplexed flows is at the 
||lower bound of
||the range where statistical multiplexing can be applied on 
|any link and
||the number of possible ingress to egress relations passing 
|this link is
||big enough to lead to (pre-)congestion by admission of a single flow
||with a reasonable probability. I don't want to stop people 
|from working
||on this issue, but I'd favour PCN to finish standards for an 
||operational
||environment where the probability of a single admitted flow causing
||congestion on a link is extremly low. 
||
||Regards,
||
||Rudiger
||
||
||_______________________________________________
||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