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

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Thu, 25 October 2007 09:36 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 1Ikz8t-00017N-1F; Thu, 25 Oct 2007 05:36:43 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikz8s-000153-AR for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:36:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz8r-000137-Vv for pcn@ietf.org; Thu, 25 Oct 2007 05:36:41 -0400
Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikz8l-0005fR-L1 for pcn@ietf.org; Thu, 25 Oct 2007 05:36:41 -0400
Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 11:36:28 +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:36:28 +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:36:28 +0200
Message-Id: <1B6169C658325341A3B8066E23919E1C4C132B@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+UAASrNzAACVCMmA=
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: babiarz@nortel.com
X-OriginalArrivalTime: 25 Oct 2007 09:36:28.0646 (UTC) FILETIME=[84D04860:01C816EA]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
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,

as an add on: if these are all CPEs and probing is 
restricted to CPEs, it doesn't matter much to me. 
I'm having more of a problem, if a backbone edge 
router or any other backbone edge system 
(like carrier VoIP gateways) are expected to probe.

If it is the CPE which is probing, this traffic is 
standard PCN traffic to the carrier. It is forwarded 
and accounted like standard PCN traffic by the carrier.

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