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

["Joel M. Halpern" <[e-mail]>]

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