Re: [PCN] PCN edge behaviour experiment

Bob Briscoe <bob.briscoe@bt.com> Thu, 22 March 2012 19:06 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: pcn@ietfa.amsl.com
Delivered-To: pcn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8318621E802A for <pcn@ietfa.amsl.com>; Thu, 22 Mar 2012 12:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.135
X-Spam-Level:
X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZvM73EYEcL3 for <pcn@ietfa.amsl.com>; Thu, 22 Mar 2012 12:06:09 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5B21E801F for <pcn@ietf.org>; Thu, 22 Mar 2012 12:06:09 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:05:49 +0000
Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:05:45 +0000
Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 19:05:42 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1332443141986; Thu, 22 Mar 2012 19:05:41 +0000
Received: from MUT.jungle.bt.co.uk ([10.73.129.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MJ5c7J028978; Thu, 22 Mar 2012 19:05:38 GMT
Message-ID: <201203221905.q2MJ5c7J028978@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 22 Mar 2012 19:05:38 +0000
To: Michael Menth <menth@informatik.uni-tuebingen.de>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <4F68F318.1000107@informatik.uni-tuebingen.de>
References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> <4F68F278.50108@gmail.com> <4F68F318.1000107@informatik.uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN edge behaviour experiment
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2012 19:06:10 -0000

Michael,

One way to do this would be to administratively shut down a link or 
node, allow protection to shift traffic and monitor whether PCN 
starts admission control. But it would be a brave operator who did 
this with live traffic, even if it had been simulated first.

I guess you might do it for a few tens of seconds when you know 
measured traffic will fit into protection capacity but above the 
admissable rate, check it works then bring the link back up.


Bob

At 21:14 20/03/2012, Michael Menth wrote:
>I don't suggest artifical traffic to cause admitted traffic 
>exceeding the PCN threshold but real traffic. A planned experiment 
>does not imply artifical traffic.
>
>Am 20.03.2012 22:11, schrieb Tom Taylor:
>>Good points. That means the experiment doesn't have to run very 
>>long to meet the first two objectives. I do have one concern that 
>>if you introduce artificial traffic then maybe you don't get the 
>>same outcome that real traffic gives you. I figure it's inevitable 
>>that the benefits of PCN with real traffic in a real network will 
>>be less than our simulations show, if only because real networks 
>>tend to be over-provided with capacity.
>>
>>On 20/03/2012 4:52 PM, Michael Menth wrote:
>>>Hi Tom,
>>>
>>>
>>>Am 20.03.2012 21:18, schrieb Tom Taylor:
>>>>I am making what I trust will be the final revisions to the edge
>>>>behaviour documents in response to IESG comments. Amongst other
>>>>things, this is the text I propose to add in the introduction to
>>>>justify the Experimental status of the documents. The text will be the
>>>>same for CL and for SM, following on Ruediger's observation that both
>>>>behaviours are valid in different contexts. Comments are welcomed.
>>>>
>>>>---
>>>>
>>>>This document describes an experimental edge node behaviour to
>>>>implement PCN in a network. The experiment may be run in a network in
>>>>which a substantial proportion of the traffic carried is in the form
>>>>of inelastic flows and where admission control of micro-flows is
>>>>applied at the edge. For the effects of PCN to be observable, at least
>>>>some links of the network should be running near or at capacity.
>>>Better: "the aggregate rate of admitted flows on some links should come
>>>close to the bandwidths of these links."
>>>
>>>>The amount of effort required to prepare the network for the
>>>>experiment (see Section 5.1) may constrain the size of network to
>>>>which it is applied. The purposes of the experiment are:
>>>>
>>>>- to validate the specification of the CL [SM] edge behaviour;
>>>>
>>>>- to evaluate the effectiveness of the CL [SM] edge behaviour in
>>>>preserving quality of service for admitted flows; and
>>>>
>>>>- to evaluate PCN's potential for reducing the amount of capital and
>>>>operational costs in comparison to alternative methods of assuring
>>>>quality of service.
>>>>
>>>>For the first two objectives, the experiment should run long enough
>>>>for the network to experience sharp peaks of traffic in at least some
>>>>directions.
>>>These peaks could be intentionally caused for the sake of the experiment
>>>so that the effect of admission control is visible.
>>>
>>>>It would also be desirable to observe PCN performance in the face of
>>>>failures in the network. A period in the order of a month or two in
>>>>busy season may be enough. The third objective is more difficult, and
>>>>could require observation over a period long enough for traffic demand
>>>>to grow to the point where additional capacity must be provisioned at
>>>>some points in the network.
>>>Also failures could be intentionally caused for the sake of the
>>>experiment. Capacity shortage on backup paths could also be planned for
>>>so that the effect of flow termination is visible.
>>>
>>>Best wishes,
>>>
>>>Michael
>>>
>>>>_______________________________________________
>>>>PCN mailing list
>>>>PCN@ietf.org
>>>>https://www.ietf.org/mailman/listinfo/pcn
>
>--
>Prof. Dr. habil. Michael Menth
>University of Tuebingen
>Faculty of Science
>Department of Computer Science
>Chair of Communication Networks
>Sand 13, 72076 Tuebingen, Germany
>phone: (+49)-7071/29-70505
>fax: (+49)-7071/29-5220
>mailto:menth@uni-tuebingen.de
>http://kn.inf.uni-tuebingen.de
>
>_______________________________________________
>PCN mailing list
>PCN@ietf.org
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design