Re: [Netslices] Reliability & Availability in NetSling

Stewart Bryant <stewart.bryant@gmail.com> Fri, 11 August 2017 08:26 UTC

Return-Path: <stewart.bryant@gmail.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 2721113257F for <netslices@ietfa.amsl.com>; Fri, 11 Aug 2017 01:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1Y4W57DWjHGO for <netslices@ietfa.amsl.com>; Fri, 11 Aug 2017 01:26:24 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70B2132558 for <netslices@ietf.org>; Fri, 11 Aug 2017 01:26:23 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id y43so10914713wrd.3 for <netslices@ietf.org>; Fri, 11 Aug 2017 01:26:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=8t0TQu12oUD3fS83sDonnr96D8ZEwH/hjVC9rYYNMTQ=; b=l0VGxwbDZ1mTbWZ3Elc925SewjPyxFfzJpIu1cKdrA+GNqvWE2lINgde4cZM3RRxAB 0BQQZ6j0xIInNCtr2ix3Fj/truxjs4FWCHTez3QtZ7yo15o9WMrqoXyUoYofO9AsCiKh y9UeXlKPJMHzQP/1wmyo3Q0Xq2yrNO4ZOgDufcE5ytiSRIIjd5zRk8RuI5QDzwITExLP L9jjfyfHfiXD+xwyswsLwrNdZmx8XVWruhtx9krNf5IcHDd7XuThkSWRyx9kUUhPNNVT dICjqAtoyi4E0kD8hl/gmV3m2AoPR/RttijnXP4uag3/zoiMC9H33kYRP1JY9Jeyu++f 1pag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8t0TQu12oUD3fS83sDonnr96D8ZEwH/hjVC9rYYNMTQ=; b=kzWmX9yAITFtsJxdXFdnJXcGJjwE/yiqPAM8KSdrHdCn1ZWGkpui7e7zmLTztn2Kgk pxrqa7DXeZlWhe3+zphiK2QbxFsEtqbqxInNkIzdD+0wAILDxLUWtCErPLt7xOhhweda 5SLnL3cyXueP/KOpaYwIG1lYkH+6qIn0UBWzgdv6FBvR+pRGV6dn+qwQWy4arUzZBLpd r/KtWwDQaJsQnHrnjvXtmOAZU0VJzwxgoqiuoCtdjyWSLLXZ5JhKjXiWuI4mgPixK38a gHOhkhEJWnK7a/DIa5sYkGvDWYFMnYsxboDBK3PpV4bYfqdjhb8pQ41RKxLJsKukGXcN m3aA==
X-Gm-Message-State: AHYfb5jttqvJcPaV9fxlq/w0CGmsqa/k6f5a+A3+1CcwD90qSXcR5agN mw7VE/dJAzGhcsb9CNw=
X-Received: by 10.223.135.175 with SMTP id b44mr9889242wrb.48.1502439982031; Fri, 11 Aug 2017 01:26:22 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 195sm737039wmv.25.2017.08.11.01.26.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 01:26:21 -0700 (PDT)
To: "qiangli (D)" <qiangli3@huawei.com>, "netslices@ietf.org" <netslices@ietf.org>
References: <06C389826B926F48A557D5DB5A54C4ED2A5743F7@dggemi509-mbs.china.huawei.com> <TY1PR06MB0928FED40F8D136737C6036187880@TY1PR06MB0928.apcprd06.prod.outlook.com> <20170810044200.GB1828@spectre> <17a7e36c-21c7-93ef-8058-573019280dfc@gmail.com> <06C389826B926F48A557D5DB5A54C4ED2A5745E2@dggemi509-mbs.china.huawei.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <af0cd20c-5747-31bf-cdc7-6af146bf2a87@gmail.com>
Date: Fri, 11 Aug 2017 09:26:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED2A5745E2@dggemi509-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------76AC44FF402B199D3A72C865"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/4VBwsl6TQ1xI8qNd9_Qg2ryRrJY>
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 08:26:27 -0000

 From a tenant's perspective, which arguably is the most important 
perspective the key characteristics of interest is  surely "The Mean 
Time Between Failures (MTBF) to maintain a defined QOS requirement." 
together with the duration of those periods.

With that information you can the viability of your application over the 
slice, and the impact on your business.

- Stewart


On 11/08/2017 08:47, qiangli (D) wrote:
>
> 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
>