Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 17 November 2020 10:28 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 8F5923A0E7A; Tue, 17 Nov 2020 02:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 FPAXhzE_tCJG; Tue, 17 Nov 2020 02:28:40 -0800 (PST)
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 E174B3A0E78; Tue, 17 Nov 2020 02:28:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Cb2Gb4mvhz6GD2N; Tue, 17 Nov 2020 02:28:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605608919; bh=JgE3JNgR2RJnr/0ml35N661bbBDgP4QWD1QEcVSmG0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CGDOZ32GqXnN8f/eq10bOrVZsoGN0uXhmGSQrE/VDVQ6JLjIrlVmVybv59ebqSrRc ls1Vp0FYq6NvF5E96CZ+J+ayzPhJjqid/h0cKPbwx6EcIVbLLVRMcOubv5q687SZv9 ytWKVxDeYYdnTXes3EKCHvooAVdwXom+UMMZ+CDk=
X-Quarantine-ID: <pUygzxPMO_YM>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (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 4Cb2Gb0gkGz6GCkm; Tue, 17 Nov 2020 02:28:39 -0800 (PST)
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: teas@ietf.org, draft-nsdt-teas-ietf-network-slice-definition@ietf.org
References: <059e01d6b6ce$0f74a830$2e5df890$@olddog.co.uk> <9e8170c6-399b-e954-2abb-5e5f425f172a@joelhalpern.com> <13178999-9168-46fb-8455-36d4d5683a2e@Spark> <62c127a5-9230-d105-04b7-4b061fdd43c1@joelhalpern.com> <a9d968ed-90af-4889-8cc8-bc57b76edbf3@Spark> <879FFB4D-3E9B-498C-BF40-B30252A8F273@gmail.com> <d91f339b-ca19-cd1c-651f-45d8c8c8784d@joelhalpern.com> <4ACEF52F-BF99-4B45-BFA0-B0C221E4D4E7@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <62c75774-4032-854f-f03b-4d5127819a68@joelhalpern.com>
Date: Tue, 17 Nov 2020 05:28:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <4ACEF52F-BF99-4B45-BFA0-B0C221E4D4E7@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/YiEmQ-g-t8EabI2NzU8-OBoBw_U>
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation
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: Tue, 17 Nov 2020 10:28:42 -0000

Is this analogous to specifying a burst rate with several rates over 
several time periods (only we are talking about operator ccommitments 
rather than customer commitments)?

If so, might this be something like a multi-level delay bound 
commitment, e.g.
For a given pair of ports
99% of your traffic will get there in 10 ms, and
90% of your traffic will get there in 100 ms
(I know, sloppy example, just trying to see if I am understanding the idea.)

If that is the idea, I am missing the aspect of "from outside".  From 
the customers perspective all problems are "from outside".  Whether that 
outside is a backhoe or competing traffic.

Yours,
Joel

On 11/17/2020 5:22 AM, Stewart Bryant wrote:
> They are terms from the timing world where you look at a defect in terms 
> of its probability within a window within a larger observation period.
> 
> http://www.chronos.co.uk/files/pdfs/itsf/2008/Day2/Packet_TDEV_MTIE_and_MATIE_for_Estimating_the_Frequency_and_Phase_Stability_of_a_Packet_Slave_Clock_(Antti_Pietilainen,_NSN).pdf 
> <http://www.chronos.co.uk/files/pdfs/itsf/2008/Day2/Packet_TDEV_MTIE_and_MATIE_for_Estimating_the_Frequency_and_Phase_Stability_of_a_Packet_Slave_Clock_(Antti_Pietilainen,_NSN).pdf>
> 
> ITU define MTIE in G.810, but they are looking at a different class of 
> application (frequency transfer), but I think the concept translates 
> over here.
> 
> If you look at slide 5 “MTIE of a practical packet clock” you get the 
> idea, but I think it needs expanding and applying to other characteristics.
> 
> Now some of the error sources will be within the slice, but we also need 
> to worry about error sources induced from outside the slice.
> 
> Best regards
> 
> Stewart
> 
> 
> 
>> On 17 Nov 2020, at 10:05, Joel Halpern Direct 
>> <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>> wrote:
>>
>> Stewart, I think you are raising an interesting question, but one 
>> where I got lost part way through.
>>
>> Can you elaborate one what you mean by "something analogous to MTIE 
>> and TDEV to describe packet and network interaction".
>>
>> Thank you,
>> Joel
>>
>> On 11/17/2020 4:57 AM, Stewart Bryant wrote:
>>>> On 9 Nov 2020, at 23:37, Jeff Tantsura <jefftant.ietf@gmail.com 
>>>> <mailto:jefftant.ietf@gmail.com> <mailto:jefftant.ietf@gmail.com 
>>>> <mailto:jefftant.ietf@gmail.com>>> wrote:
>>>>
>>>> I don’t think mixing performance objectives with isolation is a 
>>>> great idea though,
>>>> an SLA doesn’t change because there’s someone else sharing 
>>>> infrastructure with you, it is well understood that any changes 
>>>> within other customers should not affect you.
>>> No, but in this class of networks the interaction between customers 
>>> may be a lot more sensitive and detailed than we are used to. For 
>>> example the single metrics that we normally associate with delay and 
>>> jitter will likely become a mask in the same way that time and 
>>> frequency transfer system find necessary to completely specify and 
>>> instrument the behaviour of the subs system. We will likely need 
>>> something analogous to MTIE and TDEV to describe packet and network 
>>> interaction.
>>> I therefore think it is useful to have an umbrella term for concept 
>>> and the set of metrics that are of necessity more complex and 
>>> critical than we are used to.
>>> A possible alternative umbrella term is network cross talk. We 
>>> understand the concept of crosstalk at the physical layer. The 
>>> concept here in terms of performance is that packets do not interact 
>>> at the micro level as well as the more normal macro level.
>>> However, isolation has other feature that we need to think about 
>>> under this umbrella, for example the need to only mix certain types 
>>> of traffic allow (or exclude) traffic to flow over certain 
>>> geographies or through nodes manufactured by certain countries. We do 
>>> not have to agree with these constraints, but we need to accept that 
>>> they are becoming a reality.
>>> Now we could achieve the above by buying dedicated fibre or dedicated 
>>> hardware, but that that does not support economies of scale.
>>> I would be fine with us using a term other than isolation, but I 
>>> think it is worthwhile highlighting that we are not in “ordinary” SLA 
>>> territory with this, but that it is more complex and more detailed, 
>>> and a top level term to group these characteristics is in my view 
>>> helpful.
>>> Best regards
>>> Stewart
>