RE: [PCN] traffic matrix scenario
<ben.strulo@bt.com> Wed, 31 October 2007 10:37 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 1InAx0-00071d-1l; Wed, 31 Oct 2007 06:37:30 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InAwz-00071V-7p for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 06:37:29 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InAwy-00071C-Ru for pcn@ietf.org; Wed, 31 Oct 2007 06:37:28 -0400
Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InAwy-00060f-BE for pcn@ietf.org; Wed, 31 Oct 2007 06:37:28 -0400
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:37:27 +0000
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] traffic matrix scenario
Date: Wed, 31 Oct 2007 10:37:26 -0000
Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <3AD8370E-3CA4-48D7-9BC8-426ECC7BA320@nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] traffic matrix scenario
Thread-Index: AcgblgBwA5JkK5klSC+Vpq47uI0BdgAEOZgg
From: ben.strulo@bt.com
To: lars.eggert@nokia.com
X-OriginalArrivalTime: 31 Oct 2007 10:37:27.0207 (UTC) FILETIME=[07F6E370:01C81BAA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
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
Lars, All > But this only means that there is a *potential* for a problem. > > Do you have an estimate on how likely it is that a sufficient > number of new flows start transmitting over these empty > aggregates at roughly the same time, such that they together > can push the bottleneck straight into overload? 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. 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