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

Joel Halpern Direct <jmh.direct@joelhalpern.com> Sun, 26 April 2020 15:57 UTC

Return-Path: <jmh.direct@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 C60E33A09E5 for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 08:57:22 -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 ycF_RI30rR3O for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 08:57:21 -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 F0BE43A09DC for <teas@ietf.org>; Sun, 26 Apr 2020 08:57:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 499CGS5Cqtz6GDxT; Sun, 26 Apr 2020 08:57:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587916640; bh=Bq91/gsSUftQTFhgwh1xV2MG5uExQ8nUm9cncXRaCQw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ImJFR7tYiBz0ZBsTxeW13CwoKgAbIKVJe9KQ9c9piWaqwod5VqNaNK49x7xECJG6y Yh5WSb8BiL4eiobqKg8vjfn1Q6I1sKiK5HNQhg2vCGqGsPlCmZK2KrvMteLwcYYvz2 c3O3jJckywIT7jnfQbyHQQgDNF3FPaU3BElnU5gQ=
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 499CGR4wVNz6GCk5; Sun, 26 Apr 2020 08:57:19 -0700 (PDT)
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Zhenghaomian <zhenghaomian@huawei.com>, "teas@ietf.org" <teas@ietf.org>
References: <E0C26CAA2504C84093A49B2CAC3261A43F83079E@dggeml531-mbs.china.huawei.com> <c467e349-efd8-1519-7d8a-1f242042cfed@joelhalpern.com> <a94fe17dae2244b0af6a9303e68f1e0e@huawei.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <b54e1be6-cfd2-0bf7-1601-f6764253dfa3@joelhalpern.com>
Date: Sun, 26 Apr 2020 11:57:18 -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: <a94fe17dae2244b0af6a9303e68f1e0e@huawei.com>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/bS2xujdEbv6XYLLXwZCklu0gaiI>
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: Sun, 26 Apr 2020 15:57:23 -0000

Trimmed, in line.
Joel

On 4/26/2020 11:08 AM, Dongjie (Jimmy) wrote:
> Hi Joel,
> 
> Please see some replies inline:
> 
>> -----Original Message-----
>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: Sunday, April 26, 2020 10:52 AM
>> To: Zhenghaomian <zhenghaomian@huawei.com>om>; teas@ietf.org
>> Subject: Re: [Teas] Network Slicing design team definitions - isolation and
>> resolution
>>
...
>> More importantly, it is not something the customer has any way to verify.
>> There is no test a customer can run that will verify this.
>> Making unverifiable promises is rarely a useful thing to do.
> 
> Totally agree that tools for verification is important. As mentioned in Haomian's mail, isolation can be verified with suitable tools which can be used to collect the information at the necessary places with a suitable interval. And it is important that customers can be provided with such tools to monitor the performance and be informed of SLA violation.

As far as I can tell, the observable that you describe is latency 
variation (or maybe loss).  Fine, describe the SLO in terms of latency 
variation  (or loss).  Given that there are always imperfections in the 
system, the customer may think that the issue is isolation.  But what he 
can observe, and as far as I can tell what he cares about, is delay 
variation, loss, or other factors that affect his traffic.

To use a different example, I have learned from the advocates to hate 
bufferbloat.  But even their tests measure delay, delay variation, etc. 
They then infer the presence of large buffers.  But in fact, if the 
large buffers are present but never used, we would all be happy.  So the 
SLO on this would be in terms of latency, latency variation, loss, etc. 
Not bufferbloat.`

Yours,
Joel

> 
> Best regards,
> Jie
> 
>>
>> Yours,
>> Joel
>>
>> PS: Note that I understand that operators get asked for odd things mby
>> customers.  But if we are going to define standards to support it, we need to
>> understand the actual need.
>>
>> On 4/25/2020 10:44 PM, Zhenghaomian wrote:
>>> Not sure if I understand your question correctly.
>>> Well, it's reasonable for people to request hard isolation because 'I don't want
>> my data to be transported together with other people's data'.
>>> For delivery this can be achieved by separating physical devices/connections,
>> which are visible to users. For example dedicated boxes and fibers will guarantee
>> the user's data is not mixed with others...
>>>
>>> Best wishes,
>>> Haomian
>>>
>>> -----邮件原件-----
>>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> 发送时间: 2020年4月26日 10:34
>>> 收件人: Zhenghaomian <zhenghaomian@huawei.com>om>; teas@ietf.org
>>> 主题: Re: [Teas] Network Slicing design team definitions - isolation and
>>> resolution
>>>
>>> (trimmed)
>>> What is the user perceivable effect that the user is asking for when you say "if
>> the user requests isolation"?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 4/25/2020 10:31 PM, Zhenghaomian wrote:
>>>> Hi, Kiran, Joel,
>>>>
>>> ...
>>>> BTW, regarding the isolation, I don't see the necessity to argue whether it
>> should be in SLO or not. The isolation itself, can either be requested by the user
>> of the transport slice (then from NBI of TSC) to express the demand of reliability,
>> or be offered by the provider of the transport slice (then from the SBI of TSC) to
>> achieve the SLO requested from the user. In other words, if the user requests
>> certain level of isolation in an SLO, such isolation should be provided; if the user
>> does not request certain level of isolation (no isolation request in SLO), then
>> there may be some isolation provided to satisfy the user's request.
>>>>
>>>> Best wishes,
>>>> Haomian
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas