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

"Jozef Babiarz" <babiarz@nortel.com> Fri, 19 October 2007 14:20 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 1Iisi6-0002w6-Kx; Fri, 19 Oct 2007 10:20:22 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iisi4-0002qx-P1 for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 10:20:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisi3-0002pj-Ut for pcn@ietf.org; Fri, 19 Oct 2007 10:20:19 -0400
Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iishx-00011y-PS for pcn@ietf.org; Fri, 19 Oct 2007 10:20:19 -0400
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 l9JEJt714596; Fri, 19 Oct 2007 14:19:55 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: Correction: RE: [PCN] Architecture draft - probing section & general updates.
Date: Fri, 19 Oct 2007 10:19:52 -0400
Message-ID: <9671A92C3C8B5744BC97F855F7CB646512B4E7B4@zcarhxm1.corp.nortel.com>
In-Reply-To: <BABC859E6D0B9A4D8448CC7F41CD2B070551D4DF@xmb-rtp-203.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Correction: RE: [PCN] Architecture draft - probing section & general updates.
Thread-Index: AcgSUBT+aymtm9fVToiQGCN1HeZKlQAAC8jQAADCIFAAACiNoA==
References: <BABC859E6D0B9A4D8448CC7F41CD2B070551D4DF@xmb-rtp-203.amer.cisco.com>
From: Jozef Babiarz <babiarz@nortel.com>
To: "Anna Charny (acharny)" <acharny@cisco.com>, Lars Eggert <lars.eggert@nokia.com>
X-Spam-Score: 0.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

I agree with Anna, and would like to add that the marking mechanism in
core network needs to work equally well when ingress-egress aggregates
passing through bottleneck router have small or large number of flows.
Choosing marking approach that only works for one case is not that
useful, at lest to me and my customers that are interested in PCN.

On the probing issue, there are many (two+) methods currently defined
and some already used in IP networks as well new methods that could be
defined for possible use with PCN for admission control. I'm OK with
deferring the selection of already defined protocol(s) or definition of
new probing protocol until later date. However, I believe strongly that
the architecture and the selection of PCN marking approach needs to take
into consideration that probing may be part of some
solutions/deployments and that details will be defined at some future
time. 

Regards, Joe
email:babiarz@nortel.com
Telephone:613-763-6098
-----Original Message-----
From: Anna Charny (acharny) [mailto:acharny@cisco.com] 
Sent: October 19, 2007 9:25 AM
To: Anna Charny (acharny); Lars Eggert
Cc: pcn@ietf.org
Subject: Correction: RE: [PCN] Architecture draft - probing section &
general updates.

A typo in my previous message: I meant to say the charter does NOT
restrict the low ingress-egress aggregation.  Edited the appropriate
sentense below...

Anna

> -----Original Message-----
> From: Anna Charny (acharny) 
> Sent: Friday, October 19, 2007 9:23 AM
> To: 'Lars Eggert'
> Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org
> Subject: RE: [PCN] Architecture draft - probing section & 
> general updates.
> 
> Hi Lars,
> 
> On the low agfgregation point, please see below: 
> 
> > -----Original Message-----
> > From: Lars Eggert [mailto:lars.eggert@nokia.com]
> > Sent: Friday, October 19, 2007 8:58 AM
> > To: Anna Charny (acharny)
> > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org
> > Subject: Re: [PCN] Architecture draft - probing section & general 
> > updates.
> > 
> > On 2007-10-16, at 21:55, ext Anna Charny (acharny) wrote:
> > > Yes, Robert's is a fair concern to which no obvious 
> solution is in 
> > > sight. Different equipment might use different algorithms 
> and might 
> > > use different fields for ECMP load-balancing under different 
> > > circumstances.
> > > IMHO this is a killer argument of why the use of probing for 
> > > discovering the state of ECMP paths should not be 
> considered within 
> > > the scope of PCN WG.
> > 
> > Agreed.
> > 
> > > There remains a question of whether probing can/should be
> > considerd to
> > > probe the path regardless of the ECMP issue.  I see most of
> > its value
> > > in flash crowd situations in combination with low ingress-egress 
> > > agregation.
> > 
> > I note that scenarios with low aggregation aren't in scope of the
> > charter:
> > 
> >    The initial scope of the PCN WG is restricted by the following
> >    assumptions:
> > ...
> >    (C) the number of flows across any potential aggregation 
> bottleneck
> >    is sufficiently large for stateless, statistical mechanisms
> >    to be effective
> 
> Actually,  I did not mean low aggregation *at the 
> bottleneck*, which is what the charter seems to restrict.  
> Rather I meant the case when the bottleneck has high 
> aggregation, but traffic on that bottleneck comes from a 
> large number of ingress-egress pairs, each having very low 
> aggregation levels.  I believe technically the charter does  NOT 
> put any explicit restrictions on the scope for ingress-egress 
> aggregation. 
> 
> Perhaps the WG should consider whether it is reasonable to 
> impose  restrictions on the *ingress-egress* aggregation 
> levels as well.  An argument can be made that in practice a 
> large number of ingress-egress pairs may only have a few 
> flows, even when the bottleneck aggregations are large. 
> 
> The decision on whether low ingress-egress aggregation level 
> is in scope seems to be important for choosing among the 
> various approaches proposed to the WG, as some of them are 
> substantially more sensitive to the low ingress-egress 
> aggregations than others (e.g. single marking does not 
> perform well at very low levels of aggregation, as we showed 
> at the last meeting).  
> 
> Perhaps an explicit discussion on the assumptions regarding 
> the expected levels of ingress-egress aggregations is needed 
> on the list? 
> 
> Towards that discussion, my personal view is that in the long 
> range ignoring low levels of ingress-egress aggregation 
> levels will severely limit the viability/usefulness of the 
> technology.  However, perhaps as an initial step it would be 
> OK to assume moderate to high aggregation levels, as long as 
> a clear path is visible on how to address low aggregations in 
> the future within the scope of defined behaviors.  But I 
> think it is important to have a clear consensus on this point. 
> 
> Anna 
> 
> > 
> > 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