Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Some comments inline.



Regards

Xuesong



-----Original Message-----
From: Teas [mailto:[e-mail]] On Behalf Of Joel M. Halpern
Sent: Monday, August 31, 2020 12:11 PM
To: Gengxuesong (Geng Xuesong) <[e-mail]>
Cc: TEAS WG <[e-mail]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix



You list two points.  I am confused by both of them.  I will paraphrase each with my confusion.  (Posasibly my paraphrase will indicate that I am misunderstanding you.  If so, please clarify and accept my apologies for misunderstanding.



Point 1) networks change.  You then claim isolation says that my network changes won't affect you.  Isn't that the point of attaching a confidence to an SLO.  If I tell you that I will meet the requirements 99.99% of the time, that seems to be what the custoemr is asking for.

As I ahve said before, the custoemr does not seem to care whether a failure is caused by competing traffic or by a network failure or a backhoe or ... He is still not getting what he wants.  So I expect a customer to want a commitment that he will get what he has been promised, not merely avoidance of a specific failure mode.



A crude example for illustrative purposes only : When SLO couldn’t be met, 50% of the cases is caused by myself and 50% of the cases is caused by others. Isolation could eliminate half of the failure cases. If others are always rude and greedy, the benefits from isolation may be more obvious. Basically, isolation guarantees people only get the part they have paid and decreases the probability of SLO ruining. That’s the benefit for the customer.

I like the expression of “attaching a confidence to an SLO”, if “confidence” here means “confidence level” mathematically . I think no SLO guarantee could be achieved(technically strict rather than experience value) without isolation, considering that behavior of others could not be expected. We could never provide network service with 0 loss, 20ms latency, 5ms jitter, when we share the network with another guy who filling too much traffic to the network all the time. That’s the benefit for providing other SLO attributes.



Point 2) What I do in my slice (VPN, traffic set, ...) is my problem.

Mostly agreed.  But what does that have to do with isolation?Or with SLO? The one aspect on which I disagree is that in order to operate his network, an operator may well police high priority traffic from a customer to stay within the limit that the customer has agreed to.  In that sense, an end customer failure may make more work for the operator, not just the customer.  But that still has nothing to do with isolation.



It is a good point. I agree that if the access control of high priority traffic, which takes up only a very small fraction of the network bandwidth, is well executed, for this part of the traffic, the most of the problem may not be inside the operator’s network. However, this method is not so easy as it looks like, some issues should be considered:

1.       How to “well police” the high priority in the whole network, where every hop could be the bottleneck theoretically;

2.       If the traffic is simply divided into high priority and low priority, whether different kinds of requirements from different applications could be satisfied;

3.       With more traffic requires SLO guarantee, the percentage of high-priority traffic in the network will rise accordingly, whether “well police” still works with more traffic competes for limited network resource;

Isolation matters considering all these cases.



Once we have a document adopted (with placeholders) I would be interested to see an actionable clear defintion of "isolation".  I have not seen one to date.  Neither the text we are removing, nor the earlier text that was present, constitute such a definition.  And various people's examples have suggested very different (if vague) definitions.



I’m looking forward to a clear definition too, although it is not easy to handle all these different opinions.





Yours,

Joel



On 8/31/2020 12:00 AM, Gengxuesong (Geng Xuesong) wrote:

> Hi Joel,

>

> Good question. Answers inline.

>

> Regards

>

> Xuesong

>

> -----Original Message-----

> From: Joel M. Halpern [mailto:[e-mail]]

> Sent: Monday, August 31, 2020 11:31 AM

> To: Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>

> Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>

> Subject: Re: [Teas] WG adoption -

> draft-nsdt-teas-transport-slice-definition - Appendix

>

> Assuming the description you give below, I have two related questions.

>

> If the performance is great, why would the transport user care whether

> it is not actually isolated?

>

> Conversely, if the performance does not meet the needs, then why would

> the transport user care that isolation has been preserved?

>

> 2 perspectives:

>

> 1.The essence of performance measurement is sampling. Network changes

> all the time. Good performance at 8 o'clock doesn’t mean good

> performance at 9 o'clock. Isolation shows the fact to the transport

> user: no matter when, my performance won’t be bothered by other users.

>

> 2.Further assumption is: the traffic in my slice is under my control,

> but I can't keep my neighbors from overloading. In the context of

> isolation ensuring, if the user is still not satisfied with the

> performance, limit traffic or increase capacity inside the slice. Fair game.

>

> Yours,

>

> Joel

>

> On 8/30/2020 11:11 PM, Gengxuesong (Geng Xuesong) wrote:

>

>> Hi Greg,

>

>>

>

>> Thank you for directing the discussion to the technical nature of

>

>> isolation. Please find comments below:

>

>>

>

>> I assume that the term "isolation" is not simply a replacement for

>

>> "dedicated" andis intended to apply to cases when transport slices

>

>> share underlying infrastructure.

>

>>

>

>> I agree about your description of isolation. Although there may be

>

>> other kinds of understanding which will broaden the scope of this

>

>> concept. I will leave it to the authors and WG. The discussions below

>

>> based on the assumption that “isolation is intended to apply to cases

>

>> when transport slices share underlying infrastructure  ”.

>

>>

>

>> There is a number of performance metrics that may indicate the lack

>> of

>

>> isolation but that, in my view, can be attributed to under-isolation

>

>> (for the lack of better term at the moment) between slices as the

>

>> result of root cause analysis of increased latency and/or packet loss.

>

>>

>

>> I think here hides some basic logic behind the debate: if the

>

>> isolation could be described indirectly by other SLO attribute,

>

>> whether we still need it as an independent concept. My answer is: the

>

>> hypothetical part of the question is incorrect, because *isolation

>

>> can’t be described by other attributes, although it influences other

>

>> attributes.* A further conclusion is that : *Deterioration of other

>

>> SLO metrics is neither sufficient nor necessary for isolation

>

>> absence*. Two simple examples to defense this:

>

>>

>

>> 1.When isolation is perfectly executed that there is no interfere

>

>> among different slices, the performance could still be very terrible

>

>> if the resource inside the slice is exhausted.

>

>>

>

>> 2.When there is no isolation among slices and all the resource is

>

>> shared, the performance could still be very great if the resource is

>

>> sufficient for all the slices.

>

>>

>

>> So the trick here is: other SLO attributes (delay, jitter, loss…)

>

>> depend on whether there is enough cake to make everybody happy, and

>

>> isolation prevents other guys to touch my cake. They're relevant, but

>

>> they're different, and not interchangeable.

>

>>

>

>> That is why I agree that isolation should be clearly defined in

>

>> draft-nsdt-teas-transport-slice-definition, not in Appendix.

>

>>

>

>> Regards,

>

>>

>

>> Xuesong

>

>>

>

>> *From:*Greg Mirsky [mailto:[e-mail]]

>

>> *Sent:* Sunday, August 30, 2020 5:38 AM

>

>> *To:* Gengxuesong (Geng Xuesong) <[e-mail]

>> <mailto:[e-mail]>>

>

>> *Cc:* Jeff Tantsura <[e-mail]

>> <mailto:[e-mail]>>; TEAS WG

>

>> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>; Jari Arkko

>> <[e-mail]

> <mailto:[e-mail]>>; Vishnu Pavan

>

>> Beeram <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>

>> *Subject:* Re: [Teas] WG adoption -

>

>> draft-nsdt-teas-transport-slice-definition - Appendix

>

>>

>

>> Hi Xuesong,

>

>>

>

>> I assume that the term "isolation" is not simply a replacement for

>

>> "dedicated" andis intended to apply to cases when transport slices

>

>> share underlying infrastructure. If that is the case,I think there's

>

>> a sort of contradiction between statements "isolation is SLO" and

>

>> "isolation is not directly measurable [calculable GIM]". I wonder,

>

>> What is the opposite of isolation as a TS characteristic? I imagine

>

>> that one example of that would be a case when the flow from one slice

>

>> is using resources from another, i.e., interference between slices.

>

>> There is a number of performance metrics that may indicate the lack

>> of

>

>> isolation but that, in my view, can be attributed to under-isolation

>

>> (for the lack of better term at the moment) between slices as the

>

>> result of root cause analysis of increased latency and/or packet loss.

>

>> And even if interference from another slice doesn't result in

>

>> observable quality degradation, an operator can compare the offered

>

>> load from the customer with the availableBW. And that information

>

>> doesn't have to be measured by the client but reported by the

>> operator

>

>> in the agreed intervals and aggregated on an hourlyand dailybasis.

>

>> Certainly, we can have more cases thatconstitute the un-isolationism

>

>> of slices but that, I suspect, still will be observable, measurable,

>

>> calculable through other SLOs and only the analysis will point to the inadequate isolationof resources.

>

>>

>

>> But back to the isolation. I believe that the proposal from WG Chairs

>

>> is the best way forward. Let us explore our interpretations of the

>

>> term and work on formulating one we can build consensus (rough)

>

>> around. And if so happens that there is none, then we all get a

>> better

>

>> understanding of the problem and may get it in the new document.

>

>>

>

>> Regards,

>

>>

>

>> Greg

>

>>

>

>> On Tue, Aug 25, 2020 at 7:40 PM Gengxuesong (Geng Xuesong)

>

>> <[e-mail] <mailto:[e-mail]

> <mailto:[e-mail]%20%3cmailto:[e-mail]>>> wrote:

>

>>

>

>>     +1

>

>>

>

>>     And one more supplementary comment about  “Isolation is not a

>

>>     directly measurable SLO”. Maybe here is some fog about what is

>

>>     measurable. Isolation could not described by number/value. But it

>

>>     doesn’t mean that it is an abstract concept that could not be

>

>>     defined precisely. People are asking whether TE link is isolated

>>or

>

>>     not. It could be clarified by some deep analysis, good

>>discussions

>

>>     and clear text. There is no conclusion yet just because we don’t

>

>>     even allow it to be existing in an WG document. And I don’t think

>

>>     the definition of other SDOs really matter. Because isolation in

>

>>     mobile network is different from isolation in IETF. If there is

>

>>     requirement in IETF, define it in IETF. We can’t say we could not

>

>>     get to somewhere because there is no path. Build the path by ourselves.

>

>>

>

>>     Xuesong

>

>>

>

>>     *From:*Teas [mailto:[e-mail]

>

>>     <mailto:[e-mail]>] *On Behalf Of *Jeff Tantsura

>

>>     *Sent:* Wednesday, August 26, 2020 6:32 AM

>

>>     *To:* TEAS WG <[e-mail] <mailto:[e-mail]

> <mailto:[e-mail]%20%3cmailto:[e-mail]>>>; Jari Arkko

>

>>     <[e-mail] <mailto:[e-mail]

> <mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>

>>     *Cc:* Vishnu Pavan Beeram <[e-mail]

>

>>     <mailto:[e-mail]>>

>

>>     *Subject:* Re: [Teas] WG adoption -

>

>>     draft-nsdt-teas-transport-slice-definition - Appendix

>

>>

>

>>     I find Pavan and Lou proposal reasonable and a good/working way forward.

>

>>     While isolation is not a directly measurable SLO, it is often a

>

>>     legally binding requirement wrt service provided, could be

>>expressed

>

>>     as a physical SRLG or disjointness.

>

>>     It is also a viable constrain to be used ina path computation logic.

>

>>     There are connectivity RFIs that explciteily require full

>>physical

>

>>     separation/isolation - finance for security reasons,DCI for

>

>>     resiliency, etc.

>

>>

>

>>     We could pretend it doesn’t exist (which is the complete removal)

>>or

>

>>     find an appropriate and acceptable to the WG description as the

>

>>     document evolves.

>

>>

>

>>     Cheers,

>

>>

>

>>     Jeff

>

>>

>

>>     On Aug 25, 2020, 12:59 PM -0700, Jari Arkko <[e-mail]

>

>>     <mailto:[e-mail]>>, wrote:

>

>>

>

>>         High-level bit: I would like to see the document adopted.

>>With

>

>>         changes if needed. Let the WG decide. Design teams are there

>

>>         just for preparing proposals. Authority to do stuff is

>>entirely

>

>>         in the WG now.

>

>>

>

>>         When it comes to the isolation topic, however, FWIW, I wanted

>>to

>

>>         provide both a context from design team discussions and my

>

>>         personal perspective on this.

>

>>

>

>>         Design team discussions:

>

>>

>

>>         We’ve had variants of this discussion on almost all of the

>>calls

>

>>         we’ve had for the last year. One one side there was our

>>shared

>

>>         observation that industry uses the term isolation, and

>>(perhaps

>

>>         less widely shared conclusion) that it is important to be

>>able

>

>>         to relate to this. On the other side, there was our shared

>

>>         agreement that what matters from a requirement perspective is

>

>>         the bandwidth and other requirements, and that there are

>>several

>

>>         techniques that can provide the desired characteristic of not

>

>>         having your neighbour affect the bandwidth the service

>>provider

>

>>         has agreed to give you.

>

>>

>

>>         The text that we had was in an appendix precisely because we

>

>>         felt that the top-level SLOs should be the requirement and

>>are

>

>>         sufficient by themselves. The appendix only attempts to say

>>that

>

>>         “there’s multiple ways to achieve this, and by the way, this

>

>>         term in the industry relates to our work in this indirect way”..

>

>>

>

>>         I can appreciate that we may have failed in the task of

>>writing

>

>>         that. Delete and move on, no biggie :-)

>

>>

>

>>         Personal perspective:

>

>>

>

>>         My impression of customer requirements and how they get

>

>>         represented matches with what Joel has been saying in this thread.

>

>>

>

>>         I’m fine removing the appendix.

>

>>

>

>>         If I had my way, I would write the document based entirely on

>

>>         the primary characteristics —such as that we promise you n

>

>>         GB/s. Then I would write a footnote or appendix somewhere

>>that

>

>>         explains that this notion isolation has also been discussed

>

>>         elsewhere, and that it can be represented using the primary

>

>>         characteristics, and hence need not be discussed further in

>>this

>

>>         document. One could perhaps also point out that there are

>

>>         multiple ways to implement the primary characteristics

>>promises,

>

>>         so that those promises can be kept despite what’s happening

>>with

>

>>         your neighbour’s traffic. And leave it at that. But I

>>understand

>

>>         from this thread that people are reluctant to do that, and

>>may

>

>>         even be reluctant to write anything about isolation. I’m fine

>

>>         with that, too.

>

>>

>

>>         Jari

>

>>

>

>>         _______________________________________________

>

>>         Teas mailing list

>

>>         [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>

>

>>         https://www.ietf.org/mailman/listinfo/teas

>

>>

>

>>     _______________________________________________

>

>>     Teas mailing list

>

>>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>

>

>>     https://www.ietf.org/mailman/listinfo/teas

>

>>

>

>>

>

>> _______________________________________________

>

>> Teas mailing list

>

>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

>

>> https://www.ietf.org/mailman/listinfo/teas

>

>>

>



_______________________________________________

Teas mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/teas