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

Lars Eggert <lars.eggert@nokia.com> Fri, 19 October 2007 14:21 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 1Iisj9-0004KP-FU; Fri, 19 Oct 2007 10:21:27 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iisj7-0004Jh-Vm for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 10:21:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisj6-0004Gz-VL for pcn@ietf.org; Fri, 19 Oct 2007 10:21:24 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iisj0-00014l-Eo for pcn@ietf.org; Fri, 19 Oct 2007 10:21:24 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JEKpfI016958; Fri, 19 Oct 2007 17:21:03 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:20:54 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:18:32 +0300
Received: from [172.21.39.202] (esdhcp039202.research.nokia.com [172.21.39.202]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JEIUuP021731; Fri, 19 Oct 2007 17:18:31 +0300
In-Reply-To: <BABC859E6D0B9A4D8448CC7F41CD2B070551D4D8@xmb-rtp-203.amer.cisco.com>
References: <BABC859E6D0B9A4D8448CC7F41CD2B070551D4D8@xmb-rtp-203.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <675CA684-7FE8-4F51-B011-DD59BE1E29A1@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [PCN] Architecture draft - probing section & general updates.
Date: Fri, 19 Oct 2007 17:18:30 +0300
To: ext Anna Charny <acharny@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 19 Oct 2007 14:18:32.0497 (UTC) FILETIME=[EDBC8210:01C8125A]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
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>
Content-Type: multipart/mixed; boundary="===============1660059407=="
Errors-To: pcn-bounces@ietf.org

Hi,

On 2007-10-19, at 16:23, ext Anna Charny (acharny) wrote:
> 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 put any
> explicit restrictions on the scope for ingress-egress aggregation.

thanks for teasing these two issues apart. I had been under the  
assumption that one would come with the other, but you're correct  
that they can be unrelated.

It was the intent of the charter to initially restrict PCN to  
scenarios with significant levels of multiplexing, so that simple,  
statistical measures are effective. So I'd argue that although the  
current charter text isn't explicit about ingress-egress-pair  
aggregation levels, it was written under the assumption that they'd  
be significant.

That said, I do agree with you that it would be good to come to an  
explicit agreement on this within the WG.

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

Agreed.

I've stated my reasons for wanting PCN to focus on high-aggregation  
scenarios in previous emails. Let me add one additional argument:

I see PCN as being complementary to traditional, hop-by-hop signaled  
QoS reservation mechanisms. These mechanisms already cover scenarios  
with low-aggregation levels well. They tend to break down for high  
traffic volumes, which is exactly where I'd expect PCN to be the most  
attractive. In other words, because using PCN in low-aggregation  
scenarios means that probing is required, with the already-discussed  
complexities, delays and overheads, traditional QoS mechanisms become  
attractive. Yes, signaled QoS mechanisms are more complex than PCN,  
but not much more complex than PCN with a fully-worked out probing  
mechanism. Additionally, signaled QoS setup results in a guarantee  
that a flow can be sustained, while even with probing, PCN will only  
results in an estimate on whether a flow can be sustained.

Lars 
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn