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

"Jozef Babiarz" <babiarz@nortel.com> Wed, 24 October 2007 16:14 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 1Ikisi-0004Un-Fm; Wed, 24 Oct 2007 12:14:56 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikish-0004UA-2F for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 12:14:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikisg-0004Nx-OG for pcn@ietf.org; Wed, 24 Oct 2007 12:14:54 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkisY-00048R-Jc for pcn@ietf.org; Wed, 24 Oct 2007 12:14:52 -0400
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 l9OGESA02479; Wed, 24 Oct 2007 16:14:28 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 draft - probing section & general updates.
Date: Wed, 24 Oct 2007 12:14:21 -0400
Message-ID: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com>
In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Architecture draft - probing section & general updates.
Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAASrNzA
References: <9671A92C3C8B5744BC97F855F7CB646512C6F7D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de>
From: Jozef Babiarz <babiarz@nortel.com>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
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

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