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