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