Re: [Netslices] Reliability & Availability in NetSling

"qiangli (D)" <qiangli3@huawei.com> Fri, 11 August 2017 07:47 UTC

Return-Path: <qiangli3@huawei.com>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC7E1324E7 for <netslices@ietfa.amsl.com>; Fri, 11 Aug 2017 00:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmoybIn5xrl6 for <netslices@ietfa.amsl.com>; Fri, 11 Aug 2017 00:47:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3092313257B for <netslices@ietf.org>; Fri, 11 Aug 2017 00:47:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTE77173; Fri, 11 Aug 2017 07:47:50 +0000 (GMT)
Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 11 Aug 2017 08:47:49 +0100
Received: from DGGEMI509-MBS.china.huawei.com ([169.254.2.103]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0301.000; Fri, 11 Aug 2017 15:47:42 +0800
From: "qiangli (D)" <qiangli3@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "netslices@ietf.org" <netslices@ietf.org>
Thread-Topic: [Netslices] Reliability & Availability in NetSling
Thread-Index: AQHTEYKQIJcEjhMuTkOxxmA9sYa0YaJ8fOAAgABYO4CAAdmIoA==
Date: Fri, 11 Aug 2017 07:47:42 +0000
Message-ID: <06C389826B926F48A557D5DB5A54C4ED2A5745E2@dggemi509-mbs.china.huawei.com>
References: <06C389826B926F48A557D5DB5A54C4ED2A5743F7@dggemi509-mbs.china.huawei.com> <TY1PR06MB0928FED40F8D136737C6036187880@TY1PR06MB0928.apcprd06.prod.outlook.com> <20170810044200.GB1828@spectre> <17a7e36c-21c7-93ef-8058-573019280dfc@gmail.com>
In-Reply-To: <17a7e36c-21c7-93ef-8058-573019280dfc@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.163.138]
Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED2A5745E2dggemi509mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.598D6127.0090, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.103, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 31537d4fb943dda219c4b8b4adb2c33d
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/kDUj5K32iSuCt1hDAjrCjz6HOLo>
Subject: Re: [Netslices] Reliability & Availability in NetSling
X-BeenThere: netslices@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <netslices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netslices>, <mailto:netslices-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netslices/>
List-Post: <mailto:netslices@ietf.org>
List-Help: <mailto:netslices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netslices>, <mailto:netslices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2017 07:47:57 -0000

Hi All,

The phrase “working as expected” inspired me. For a network slice, what people expect is not only the stable working probability/time, but also the guaranteed SLA.

Try to consider from tenant’s perspective, I would be very concerned about how much the promised SLA could really be achieved. I am not sure which one (availability/reliability) this concept should belong to according to ITU’s definitions.


Best regards,

Cristina QIANG

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Thursday, August 10, 2017 5:58 PM
To: netslices@ietf.org
Subject: Re: [Netslices] Reliability & Availability in NetSling


In general at IETF we associate reliable with the probability of packet delivery, and a reliable transport protocol is one that retries (at a cost of delay) until the packet is delivered or other factors intervene. Availability tends to refer to the ability of the network to receive packets for attempted delivery.

I looked for a formal definition in IPPM which is the WG that is concerned with measuring such things but could not find a definition.

From the ITU we can find:
Term : availability (performance)

Definition : The ability of an item to be in a state to perform a required function under given conditions at a given instant of time or over a given time interval, assuming that the required external resources are provided.
NOTE 1 – This ability depends on the combined aspects of the reliability performance, the maintainability performance and the maintenance support performance.
NOTE 2 – Required external resources, other than maintenance resources do not affect the availability performance of the item.


Term : reliability (performance)

Definition : The ability of an item to perform a required function under given conditions for a given time interval.
NOTE 1 – It is generally assumed that the item is in a state to perform this required function at the beginning of the time interval.
NOTE 2 – Generally, reliability performance is quantified using appropriate measures. In some applications, these measures include an expression of reliability performance as a probability, which is also called reliability.


or
Term : reliability characteristic

Definition : The Mean Time Between Failures (MTBF) to maintain a defined QOS requirement.


- Stewart
On 10/08/2017 05:42, Pedro Martinez-Julia wrote:

Dear all,



I personally think it is better to use the industrial definitions but,

being purist, we can find important differences between them. While

availability is the probability for a system to work as expected in some

period of time (99.999% of time), reliability is a broader term that

refers to the different situations in which a system will be able to

overcome without breaking. In some cases, the latter can incorporate the

former, but not in all of them.



For network slicing we can keep the definition commonly used by industry

with the necessary details to make clear the aspects that differentiate

them. I would keep "working as expected for some period of time" related

to availability and "resistant to disparate situations" to reliability.



Regards,

Pedro





On Thu, Aug 10, 2017 at 02:44:09AM +0000, GENG Liang wrote:

Hi Cristina,



Interestingly we were discussing this confusion with few industrial partners recently. In telecommunication language we normally use "Reliability" to refer the probability a network is stably run (i.e. 99.999% of time). This is also regarded as network "Availability". However, "Reliability" in industrial verticals is more comprehensive - including not only network availability parameter but also mechanics, electricity etc.



Personally I think, network slicing is still looking at network regime where I believe Reliability means the percentage of time a connection is available. But we you sell this concept to industrial verticals, they may think differently.



________________________________

Liang GENG

China Mobile Research Institute



From: qiangli (D)<mailto:qiangli3@huawei.com><mailto:qiangli3@huawei.com>

Date: 2017-08-10 10:04

To: netslices@ietf.org<mailto:netslices@ietf.org><mailto:netslices@ietf.org><mailto:netslices@ietf.org>

Subject: [Netslices] Reliability & Availability in NetSling

Hi All,



I was confused when I was reading some NetSlicing related materials. It seems that “Reliability” supported by Netslicing refers to the probability that a network slice could work stably, or other similar metrics. But, shouldn’t this be the defination of “Availability”? Then what does reliability mean in NetSlicing?





Best regards,



Cristina QIANG





_______________________________________________

Netslices mailing list

Netslices@ietf.org<mailto:Netslices@ietf.org>

https://www.ietf.org/mailman/listinfo/netslices