[Teas-ns-dt] Models Discussion - specifically, SLO groups, in the current model draft

[Eric Gray <[e-mail]>]

Fellow design team members, et al:

I have a number of issues with both the draft, and the discussions we've had about it, but I would prefer to use this thread to focus on the "SLO Group" concept.  I hope to start other threads to discuss, for instance, what we mean by a transport slice "end-point."

As far as I can tell, we've had very little discussion about Modeling work on the mailing list - beyond simple announcements about new versions of Bo's draft, and a few (mostly unanswered) comments about the draft.

I have looked at the latest version of the model draft, and I was present during the discussion of this draft today, and the discussion of the previous draft last Thursday.

In today's discussion, we talked briefly about the concept of an SLO Group.  I would like very much to have a better understanding of how this concept is to be used in modeling a transport slice service.

Speaking from a 5G network slicing (5G/NS) perspective, not to detract from other perspectives, but as an example, I have a few questions and observations related to this concept.

I agree with the comment made during the meeting that an end user does not care about the details of a slice (including what it connects, what else is connected and the details of any associated SLO) - they simply ask for a specific slice.  In the 5G network slicing case, the actual user does not even need to know that much, but instead relies on operator configuration of their UE (e.g. - phone or tablet) to select an appropriate slice identifier (about which the user knows very little other than the fact that the mobile operator has told them to expect some certain quality of experience) - so, in the 5G/NS case, the end-user might be the UE, selecting a specific slice identifier.

I also agree that the slice identifier does not identify (in any sense) the "transport slice" (more likely, "slices") that a mobile operator would use to realize the identified 5G/NS.  The mapping for this, in the 5G/NS case, would be something that the mobile operator does, most likely through software implementing their own policies.

In translating the parameters used by a 5G/NS (or analogous slicing in other applications) into specific transport slice service requirements, I do not understand how we would use the "SLO group" to efficiently represent the set of specific LSO requirements that might apply.

Suppose (as a specific example) that you have a transport slice that connects a group of three end points.  The idea - as expressed by the current draft - is that the SLO Group consists of "a group of TS-Members with [the] same SLOs in one [Transport Slice]."

There are a few issues with this definition, which I think we can overlook for a while, but the glaring difficulty is: what do we mean by SLO in this sense?  In a relatively simple case, an SLO might consist of a single metric that must be met by a transport slice - for example maximum delay, or minimum bandwidth.

It really doesn't take much imagination to come up with scenarios where an SLO group could not include more than two TS-Members, if it is constrained to have the same values for SLO parameters between any two end-points in the SLO Group.  But perhaps that is not what we mean and - by "same SLOs" - we really mean something more complicated, like "the same set of TS-Member-by-TS-Member-pair fully-specified SLO parameter values."

That would seem to be a very much overly complicated object to try to describe in a model, but I welcome someone to try.

When I first heard the discussion about this (from Reza), my first thought was this would be okay if an SLO Group could consist of as few as two TS-Members - but then I thought about the asymmetric case where the SLO parameters in either direction may differ.  This would require that a TSO Group to be able to represent directionality.

In the two-TS-Member case, this might be reasonable, but this gets very quickly unmanageably complex if a SLO group include 3 or more TS-Members - since directionality obviously needs to be represented pair-wise.  (I leave it as an exercise for bored members of this DT to figure out how this has NP related complexity.)

So, practically speaking, we probably want to limit membership in an SLO Group to two members, hence why not call it an SLO Pair?

If anyone thinks this seems to be a contrived dilemma, I refer you to the observation that the mapping of a 5G/NS to multiple  transport slices is very likely needed.  While a 5G/NS slice has specific performance objectives that are defined for that slice, realizing it over a potentially complex set of transport slices is very likey to require varying SLO parameters - even within a single transport slice, depending on how we define a transport slice.

When I review the definitions draft, it does not seem to me that there is an attempt to assert that the SLOs can be grouped - except at the level of an entire transport slice.  I think this is a relatively important feature of the way we have defined SLO in that draft.

--
Eric