RE: [PCN] traffic matrix scenario

<ben.strulo@bt.com> Wed, 31 October 2007 13:51 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 1InDz1-0000ra-Tm; Wed, 31 Oct 2007 09:51:47 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InDyz-0000p1-Qc for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:51:45 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDyy-0000oo-KU for pcn@ietf.org; Wed, 31 Oct 2007 09:51:44 -0400
Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InDyy-0005eu-3B for pcn@ietf.org; Wed, 31 Oct 2007 09:51:44 -0400
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:51:43 +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 13:51:42 -0000
Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF01631876@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <C3FFD2BB-27A1-42B7-BE97-7FA9E52D92BC@nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] traffic matrix scenario
Thread-Index: AcgbtAMUJBRNv0aKQaWXBINY+6Vq1wAD2ZMg
From: ben.strulo@bt.com
To: lars.eggert@nokia.com
X-OriginalArrivalTime: 31 Oct 2007 13:51:43.0323 (UTC) FILETIME=[2B8D0AB0:01C81BC5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
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

Hi Lars

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

Broadly speaking I think our objective is that flow termination should
only be necessary in the case of an unexpected decrease in core
capacity.  We generally do not expect an Admission Control system to
admit calls and then later terminate them in the absence of internal
network problems such as link failure.

My scenario mentioned the failure of an exchange really only as an
example of the sort of extreme scenarios we consider.  The real examples
I had in mind were simply flash crowds: widespread and unexpected
increases in call request rates with an unusual (e.g. regionally
focussed) traffic matrix.

The sort of scenario that might be particularly testing for this
particular probing issue, would be an initial anomalous traffic pattern
consisting of very heavy traffic on a few aggregates causing
pre-congestion on just a few links, followed by a subsequent widespread
increase in demand which also focuses on those links.  It is easy to
construct reasonable (though not necessarily probable) sequences of
external events that could cause this sort of traffic pattern: for
example, news reporting initially being local and progressing to
national coverage.

We would expect an Admission Control system to do a good job of
rejecting requests in this scenario.  Though this is not completely cut
and dried: it's possible a very small amount of flow termination might
be acceptable.
 
> If we aren't in agreement, then I wonder under what 
> circumstances you'd consider flow termination to be appropriate?

As I say, only really when there is a sudden and significant decrease in
core capacity.  Even then, we would normally expect to be provisioned to
deal with all but the most serious failures.

Ben Strulo


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