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

[Stewart Bryant <[e-mail]>]

> On 17 Nov 2020, at 10:28, Joel M. Halpern <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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