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

Stewart Bryant <stewart.bryant@gmail.com> Tue, 17 November 2020 14:26 UTC

Return-Path: <stewart.bryant@gmail.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 AFFB23A1383; Tue, 17 Nov 2020 06:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 pmryCQ5OlBaA; Tue, 17 Nov 2020 06:26:36 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 E53DF3A138F; Tue, 17 Nov 2020 06:26:11 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id 23so23340320wrc.8; Tue, 17 Nov 2020 06:26:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TmZ3m+QF5Gob803ZMz59v+sS0EGABiG2mBAS05jK3pA=; b=pHttUw1pmh+NO7TjWwLRY/IV7YUC0G+FRyiaCqxTDbPv7Oueshhg5edVaqy3ylV/F0 36xMs63QXkkTsvmKxyTGuirjkNcxX8S8ojE3FPpoaXU/kU8QPorKl1p1yGdNW+IGIwFi kzvvhb/dh1cAeUyGUkxteNGp6ay8/NZ3tGPxFFzu+/9KUcppBxrIexLAVUl5sU6TJ9gA A6oaDpfUyuXWIscXnRpnKr5pgQlKv9vgBblIa75aQGyq8CrZAtRRdYBRgwDoH+uLeuPd 2vDg6+QffSlXAmo/5D3L8rNWPRrTXGIRXhcz64zSnut7p78yfIhC1aG4/Q/sC/AVvMFt A2cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TmZ3m+QF5Gob803ZMz59v+sS0EGABiG2mBAS05jK3pA=; b=FsBXRDu8CW/F4eOpSVvtzunrc9nmwcaWc9UCbcZ1RF90Ag20bRC/hBa8oVeqhW83HH TDOEXz2s/5hgTSbxAfxxTpQI9xBBz4cV2XzJb00DKCVnVFrKqmjjv2aQZZt37EZcCBXU zWXNE3NgIFerqO6I1MNYWCGPNyHQRd8ZQCGztl6dj93BkDtg0AaBrxSXfgfbUo6G6457 Or8r9Y4fCEmndyCyraD0PmsMqi9vlfjmG/nOSLAv1ufSP3Q7Hr7aaKIUdaF5ymDr/6mf 99ZlGUdRM6pwEeEjP0vcp/iDHlpz/Wq46YQ4LDY0bD5+kiqUHvbON7WRJ7XSZLqpj5z4 ZcEg==
X-Gm-Message-State: AOAM533o9I+/pOWWAKcXPTVUgABMAur0bz7ldr7F0hhfYt/9yZFuq1Ik 2KUewISKoNH88CPlr+FZyes=
X-Google-Smtp-Source: ABdhPJxiD2w8hq54oyCgcQDqFu6S/oARml4lGeT+/dQftf1XPUpy/tmzXLE65k50HdiMc8StD0BK0Q==
X-Received: by 2002:a5d:634b:: with SMTP id b11mr24593731wrw.97.1605623170296; Tue, 17 Nov 2020 06:26:10 -0800 (PST)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:15b6:918e:5493:f277]) by smtp.gmail.com with ESMTPSA id d63sm3892147wmd.12.2020.11.17.06.26.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2020 06:26:09 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <62c75774-4032-854f-f03b-4d5127819a68@joelhalpern.com>
Date: Tue, 17 Nov 2020 14:26:08 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, teas@ietf.org, draft-nsdt-teas-ietf-network-slice-definition@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1D90F4C-E5C9-412F-B134-55D5E6C11305@gmail.com>
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> <62c75774-4032-854f-f03b-4d5127819a68@joelhalpern.com>
To: Joel Halpern <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XvUT_aUhVJzpY8QcOFETVwoaErY>
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 14:26:38 -0000


> On 17 Nov 2020, at 10:28, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> 
> 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

Yes, but they do it as a rolling average, so sample every 1ms (say) sample 1..10 gives 10ms, sample 2..11 give 10ms result2, then 1..100 gives 100ms result1, 2…100 gives 100ms result2.

Now there is a cool thing in the timing world, but the slope of the curve at a point in the curve tells you the cause of the error. I am not sure if this would apply to our application, but it is worth thinking about.

> (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.

I suppose you are right, but in this world it does not have to be congestion, there may be enough macro bandwidth, just not at the right ns which is on a much finer granularity than we are used to, and is more transient than we are used to.

- Stewart

> 
> 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