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 >
- [Netslices] Reliability & Availability in NetSling qiangli (D)
- Re: [Netslices] Reliability & Availability in Net… GENG Liang
- Re: [Netslices] Reliability & Availability in Net… Pedro Martinez-Julia
- Re: [Netslices] Reliability & Availability in Net… Stewart Bryant
- Re: [Netslices] Reliability & Availability in Net… qiangli (D)
- Re: [Netslices] Reliability & Availability in Net… Stewart Bryant
- Re: [Netslices] Reliability & Availability in Net… qiangli (D)
- Re: [Netslices] Reliability & Availability in Net… Stewart Bryant