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

Lars Eggert <lars.eggert@nokia.com> Tue, 23 October 2007 14:46 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 1IkL1I-00063S-K0; Tue, 23 Oct 2007 10:46:12 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkL1H-00061k-Lj for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 10:46:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkL1G-000607-Hi for pcn@ietf.org; Tue, 23 Oct 2007 10:46:10 -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 1IkL1A-0003gY-5Y for pcn@ietf.org; Tue, 23 Oct 2007 10:46:10 -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 l9NEjTui022509; Tue, 23 Oct 2007 17:46:00 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 17:45:52 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 17:17:28 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 17:17:24 +0300
Received: from [172.21.34.120] (esdhcp034120.research.nokia.com [172.21.34.120]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9NEHNXQ024692; Tue, 23 Oct 2007 17:17:24 +0300
In-Reply-To: <BABC859E6D0B9A4D8448CC7F41CD2B070558B12C@xmb-rtp-203.amer.cisco.com>
References: <BABC859E6D0B9A4D8448CC7F41CD2B070558B12C@xmb-rtp-203.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <732CE53D-C2B8-48D6-8757-EB1839E072CA@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [PCN] Architecture draft - probing section & general updates.
Date: Tue, 23 Oct 2007 17:17:19 +0300
To: ext Anna Charny <acharny@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 23 Oct 2007 14:17:24.0980 (UTC) FILETIME=[6F253B40:01C8157F]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: pcn@ietf.org, "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
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="===============1073949739=="
Errors-To: pcn-bounces@ietf.org

On 2007-10-23, at 16:38, ext Anna Charny (acharny) wrote:
> I meant roughly the following. Suppose many ingress-egress aggregates
> have on the average 1 flow.  If you have just one flow per
> ingress-egress aggregate, when this flow arrives and is the only one
> active in its ingress-egress pair, and if no
> probing of any kind is used, then effectively there is no admission
> control for this aggregate.  If many such aggregates share a  
> bottleneck,
> then effectively all these ingress-egress aggregates have to be  
> admitted
> regardless of the state of the bottleneck.  In the extreme, if all
> ingress-egress aggregates sharing a bottleneck consist of one flow,  
> then
> this bottleneck effectively does not have any admission control.  In
> such situations probing might be quite useful, as it will enable
> admission control.

To me, this looks like an awfully unlikely corner case. Do we really  
need to spend effort to make sure admission control can happen in  
this case? Can't we simply leave it to the flow termination procedure  
to kick in and remove the excess load, if such a case should really  
occur?

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