Re: [Teas] Network Slicing design team definitions - isolation and resolution

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 24 April 2020 19:55 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244C23A098C for <teas@ietfa.amsl.com>; Fri, 24 Apr 2020 12:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 WbiBScvE4Gqo for <teas@ietfa.amsl.com>; Fri, 24 Apr 2020 12:54:59 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E263A098A for <teas@ietf.org>; Fri, 24 Apr 2020 12:54:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4984db0d5Cz6G97X; Fri, 24 Apr 2020 12:54:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587758099; bh=oBsV3bIrNWZHGpjpStQjXOetgebtyJDcj4r9JKkiXkk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Yh16bOOYQM6XNsuZSVsE0iE8ZAkRmVPObpiquksDvaBJlglRk/Lz82FEfNkTp5A+b 6+MTW1effgIJ3644UrTc1OWUl7xAv1wl/nsfaY7siS+JgX6w+VzsZXJlcF/TIKW7gV RmZ+i6YoaXrcZC/NU8VDNaEpVFqVwJsn6+pBcuFI=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4984dZ2xp6z6GGh2; Fri, 24 Apr 2020 12:54:58 -0700 (PDT)
To: Kiran Makhijani <kiranm@futurewei.com>, "teas@ietf.org" <teas@ietf.org>
References: <7bfd8a09-c166-3e19-9097-360398b8cb5f@joelhalpern.com> <BYAPR13MB243781FFB1E199721A497769D9D00@BYAPR13MB2437.namprd13.prod.outlook.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <c2c5bc71-5c7b-7845-7bdb-534d17d6febe@joelhalpern.com>
Date: Fri, 24 Apr 2020 15:54:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <BYAPR13MB243781FFB1E199721A497769D9D00@BYAPR13MB2437.namprd13.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/N6gu3YcQs2Job0UQaNswxdL-oDI>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 19:55:01 -0000

Focusing first on your last comment, but retaining the rest for context.

As I understand a Transport slice, it is all about giving a well-defined 
traffic behavior to the set of traffic the user injects into the slice.

This has many dimensions in order for it to be deliverable.  It has to 
include the limits on what the user is allowed to inject.  It has to 
include how reliably / often / ... the given level will be met.
In common usage, the SLOs are the numbers used to fill these things in. 
Coupled with reliability / assurance levels, customer limits, and other 
things, to construct an SLA.  An SLO of 95 gigabits does not mean 
anything without the concomitant knowledge of how often it will be met. 
This gets even messier with things like availability, as you have to 
actually define what it means for the service to be available.  (E.g. an 
IP service that drops half the packets at random is probably not 
actually available.)

Saying 95 gigabits for 9500 flows (not sure that is even a meaningful 
parameter for packet service delivery) without a reliability is 
meaningless.  It can not be 100%.  Even the existing text notes that 
things break.  If it is 50%, it is not much of a commitment.  Which is 
why you tie the objectives to the other parameeters.  And thus need SLAs 
even if there is no money changing hands.

Your text on ranges also left me confused.
The typical case where one wants a delay range one actually wants a 
guarantee of a minimum delay, and a separate bound on delay variation. 
I do not know of a case where the customer asked the provider to slow 
down his traffic.  Nor do I know of a case where a customer said "do not 
give me more than the stated bandwidth."  the customer may want to 
control what rate he sends, but that is separate.

Hence, I am left very confused by your answers.

Yours,
Joel

PS: It is very well known, and frankly sensible, that operators when 
making these promises look at the cost of meeting the agreement, the 
operational complexity of delivering it often enough, and the price of 
failure.  And then choose different techniques to deliver the service 
based on those trade-offs.  Which, in practice, suggests that the 
orchestration likely needs visiblity to the other parameters such as how 
often it can fail.  (For example, you use FRR if you need to recover 
faster.  Based on your analysis of likely failures, non-FRR recovery 
times, ....)  We leave these kinds of things to the operators, as 
discussion of the business parameters themselves are clearly out of 
scope for the IETF.  But we have to recognize in our definitions that 
they are an intrinsic part of the task.

On 4/24/2020 3:40 PM, Kiran Makhijani wrote:
> Hi Joel,
> Please see inline.
> 
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> Sent: Thursday, April 23, 2020 5:56 PM
> To: teas@ietf.org
> Subject: [Teas] Network Slicing design team definitions - isolation and resolution
> 
> I have serious problems with these aspects of the document.
> 
> Let's start with the first discussion of isolation.  This occurs in the description of the security objective.  I have no problem with including observable security properties in objectives.  telling the customer "your traffic will be encrypted across this slice" seems a useful thing to say.  We could even discuss how the security properties of the encryption should be described, although we need to be careful about how we do so.  But isolation of flows in the network is not an external observable, not something a customer can even ask about.  Fundamentally, isolation is a way for an operator to meet a set of agreements around a set of objectives.  And this document says repeatedly that it is not about how, only what.
> [KM] There's a particular challenge with this document. Our first goal is to define transport-network slices in an independent, standalone manner, at the same reuse or build on existing/progressing IETF work. It gets off-balanced easily.
> But yours's is a fair justification. Isolation can be removed from security. I wanted this explanation so that when we develop next level of details we have some idea on what should be considered.
> 
> This gets worse when we get to the section on resolution of guarantees.
> The text begins by talking about hard vs soft guarantees.  And then explains that it means the difference between effects from interfering traffic and effects from hardware (or, presumably, software) failures.
> Except that from the perspective of the user of the slice, that is irrelevant.  If I have been given a commitment that I can send 95 gigabits per second 95% of the month, and I discover that I was unable to do so for more than 5% of the time, I as a customer will expect to invoke whatever remedy my contract gives me.  If the contract had tried to draw a distinction bassd on cause, I would have said "no, I am paying for the service.  If you can't give it to me, I'll get it somewhere else."  The customer wants the commitment met,not excuses about which cause occurred.
> [KM] I do not see a transport slice as a "contract". The typical transport slice expresses the knowledge of how much of an SLO and what failures your service can endure. for the user of the transport slice (Who is offering a service) ability to describe this is not irrelevant. When network provider receives request, they know what kind of effort they should make to keep service running. (e.g. packet loss for AR/VR should be way lower than 4K media service).
> 
> The resolution then wanders over into the issue of tolerance.  As the section correctly observes, things break.  Agreements are generally written to allow a certain amount of that.  The classic 5-9s was exactly for this purpose.  It told you how well the service would be delivered.
> IP operators can and do make promises with commitments and frequencies.
> But it is not expressed as a tolerance the way this describes it in my experience.  Rather, it is expressed by having several objectives and differing levels of commitment for them.  As a purely fictitional example to try to be clear, one might have a series of loss comitments:
>      No more than 10% loss - 99.999% of the time
>      No more than 1% loss - 99.99% of the time
>      ...
> That does not match the description of "Resolution of guarantee" in this definition document.
> [KM] This may have been misunderstood. The text is "certain tolerance level of that objective", alternately can be read as 'range' for example: bounded latency (delivery time not to exceed 9 ms, or between 7-9ms, delay variation is in 0.5 to 1ms range and so on).
> 
> And then we get section 4.1.1 which is a discussion of isolation.  It is
> a discussion which assumes the previous two elements are correct.   My
> recommendation is, rather than debating whether it is correct, is to simply remove all of 4.1.1.  If some folks involved wanted it, which is what is said on the call, then those folks need to speak up and explain what value it adds.  Currently, it misleads and confuses the reader.
> 
> As a final note, I suspect that the usage of SLO and SLA in this document does not match industry usage.  Some effort to address the mismatch might help us avoid further disconnects such as the above.
> [KM] I have always seen SLA at the business level but transport slice is something that can still be described in a tangible resource-requests. Therefore, 95gbps per month is not a description of a transport slice. A transport slice would ask: do not exceed 95gbps for max 9500 flows where each flow gets 1gbps from pt 'a' to 'b' or 'c' to 'd' for the lifetime of the service.
> -Kiran
> 
> Yours,
> Joel M. Halpern
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C3a14db2095eb4646145808d7e7ea6c9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637232866346233496&amp;sdata=cFEYu%2BcEy3YEHTjFK7tqmaVZghv%2F4VLFDaoX07OZRXg%3D&amp;reserved=0
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>