Re: [PCN] traffic matrix scenario
Lars Eggert <lars.eggert@nokia.com> Wed, 31 October 2007 11:49 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 1InC4C-0002UH-Pk; Wed, 31 Oct 2007 07:49:00 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InC4C-0002UB-1x for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 07:49:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InC4B-0002Tx-EH for pcn@ietf.org; Wed, 31 Oct 2007 07:48:59 -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 1InC45-0000aI-KV for pcn@ietf.org; Wed, 31 Oct 2007 07:48:59 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VBmj4S032408; Wed, 31 Oct 2007 13:48:45 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:48:38 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:48:37 +0200
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:48:37 +0200
Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VBmZnw004205; Wed, 31 Oct 2007 13:48:35 +0200
In-Reply-To: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net>
References: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <C3FFD2BB-27A1-42B7-BE97-7FA9E52D92BC@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [PCN] traffic matrix scenario
Date: Wed, 31 Oct 2007 13:48:34 +0200
To: "ext ben.strulo@bt.com" <ben.strulo@bt.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 31 Oct 2007 11:48:37.0651 (UTC) FILETIME=[F958EE30:01C81BB3]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
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="===============2032529576=="
Errors-To: pcn-bounces@ietf.org
Hi, On 2007-10-31, at 12:37, ext ben.strulo@bt.com wrote: > We cannot really give any measure of likelihood. In this deployment > scenario, at least, we design our network so PCN almost never rejects > calls unless the traffic matrix is highly anomalous. Such > anomalies are > inherently unpredictable. For example, a scenario we sometimes > consider > is an event which simultaneously destroys an exchange building and > causes a surge of traffic to and from the affected exchange region > consisting of emergency traffic mixed with concerned relatives calling > up to see what has happened. We cannot tell you how likely this > scenario is. But it is essential to us that PCN operates correctly in > this scenario, regardless of the scenario's precise likelihood. my definition of "operates correctly" includes the possibility of flow termination. I see flow termination as the appropriate measure if the domain gets into a state of sudden, unanticipated overload. I'd like to check if we are in agreement on this, because it is important for understanding the rest of your email (which for this reason I won't comment on yet). If we aren't in agreement, then I wonder under what circumstances you'd consider flow termination to be appropriate? Lars > So, what do we need to do to ensure that PCN does operate correctly in > the presence of extreme anomalous events? > We have a few parameters to play with. One is the margin between > pre-congestion and actual congestion. Another is provided by a cap on > the rate of admitting new flows. > > What the statistics we gave before imply is that this rate must be > quite > tightly capped, at least in the case of ingress-egress aggregates with > no flows, because the size of the pulse of flows we admit before we > get > good feedback could be being multiplied across many other > ingresses, and > together this chunk of admissions must be reliably limited to below > our > safety margin. If the rate of admission is being capped on a per > ingress basis, then the multiplication factor cannot reliably be > assumed > to be much smaller than the total number of ingresses, 100 in our > case. > If the rate of admission is being capped on a per aggregate basis then > our traffic matrix information suggests that we could have a situation > where many aggregates (a few thousand) are all ramping up into the > same > bottleneck. So the multiplication factor needs to be of that order. > > We can do the sums: given the safety margin, the time lag before > feedback becomes reliable, and the multiplication factor we can > directly > compute the maximum rate of admission per ingress and per aggregate. > Alternatively, given a desirable minimum size for this maximum rate of > admission we can compute the needed safety margin. > > What should we take to be the time lag before the feedback becomes > reliable? One component is the amount of time between admission > control > decision and data actually reaching the ingress. Can we assume > this to > be reliably bounded? The other components are then propagation and > queueing delay, alongside the time needed for the bottleneck queues to > grow and the congestion estimates to grow. Do we have good estimates > for these times? > > Ben Strulo
_______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn
- RE: [PCN] traffic matrix scenario ben.strulo
- [PCN] traffic matrix scenario philip.eardley
- Re: [PCN] traffic matrix scenario Lars Eggert
- RE: [PCN] traffic matrix scenario ben.strulo
- RE: [PCN] traffic matrix scenario Geib, Ruediger
- RE: [PCN] traffic matrix scenario Geib, Ruediger
- Re: [PCN] traffic matrix scenario Lars Eggert
- RE: [PCN] traffic matrix scenario ben.strulo
- RE: [PCN] traffic matrix scenario philip.eardley
- Re: [PCN] traffic matrix scenario Lars Eggert
- Re: [PCN] traffic matrix scenario Lars Eggert
- RE: [PCN] traffic matrix scenario Geib, Ruediger