Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

More inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

More follow-up inline.  We're getting closer.


On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:
>
> Hello Lyle and all,
>
> I think I agree with most of what you say below.  I'm concerned with how to 
> organize the information in the model.  So, for that purpose, please verify 
> whether my following understandings are correct.
>
> - The mobility context resides on a DPN.
>
> - The mobility context provides necessary information (e.g., QoS) for a 
> single mobile node.
>
> - The DPN uses it to manage data-plane traffic for that mobile node.
>
>>> This may be too broad of a view. What about a mobile node with 
>>> multiple mobility sessions? In such a case it may be managing one or 
>>> more (but not necessarily all of) the mobile node's mobility 
>>> sessions

Yes.  This is why I did not put "all" between "manage" and "data-plane".

LB > Ok.  We should probably be more explicit though for the casual observer if 
this language is used in the specification.

>
> In my earlier email on this subject, I was using Mobility Context as 
> describing something more associated with a mobile node, than with a 
> particular flow.  If you want it to mean "bearer", then we ought to call it a 
> Bearer.
>
> Maybe it would be easier to understand if we had something called a 
> "Mobile-Node Context", and in that context we had a set of Bearer Contexts 
> (or, just Bearers).  Each bearer would inherit from the Mobile Node context 
> simply by being part of it.  The Mobile Node context (serving as "parent") 
> would determine max bandwidth, IP address, etc. Back in the old days, we also 
> defined security aspects and some other factors, as part of what FPC would 
> call the "mobility context".
>
>>> We have several concepts that have hierarchy, e.g. Service Level (sr-id or 
>>> APN - apn-oi if I recall), device level, Mobility Session, bearers, flow 
>>> based filters (effectively living within a bearer).

There isn't anything about Service Level in the first part of the document, and 
I did not find anything about Service-ID that referenced mobility context.  
Mobility Context does not define Service Level. Similarly for APN.  The string 
"-oi" does not occur in the document.

Device level is a mystery to me.

Now, this isn't to say that your comment is irrelevant.  But, at minimum, the 
relevance is not spelled out in the current document.
LB> Ack.  They are not mentioned these in the documents; I was merely providing 
examples.

>>> We also have the 5G concepts as well.

We have, in fact, an infinitude of mutually contradictory 5G concepts.  
I might suggest that they look at Mobile IP, which was designed exactly 
to provide high-speed, low-latency, application-independent mobility 
management.  But, I digress.
LB> I am in agreement here but I believe that as Release 15 is finalized in 
3GPP we will see clarity.  My question would be if other next generation 
standards / technologies follow so that we have a tractable problem space but I 
too, digress.

>>>The one thing that is obvious is that the idea of hierarchy applies 
>>> whether it is pacers/shapers, bearers or filters that apply some charging / 
>>> gating / marking.  A light touch of lifecycle (fate sharing) amongst the 
>>> hierarchy,  data does not need to be repeated within the hierarchy and 
>>> building the data structure by requiring a parent id if it was a child 
>>> (implying the parent must exist!) was the best we could do without 
>>> necessarily making decisions that may appear to preclude a specific set of 
>>> mobile network technologies.

We certainly agree on the existence of hierarchy pervading our problem 
space.  And on the need to consider fate-sharing for between mobile-node 
authorizations and allocated bearers.  But my suggested approach of 
having the Bearers delineated under an inclusive Mobility Context 
provides for that in a natural way.  Perhaps the word "bearer" shows too 
much bias towards 3GPP, in which case we could simply use "mobility 
session" or "flow".
LB> Ack.  I think I would object to the use of Bearer.   Flow(s) may be too 
granular.  Maybe a verbal delineation between a Flows-Context (implying 1 or 
more) and some other concept such as Session-Context (old terminology) or 
Mobility-Context.imo though it may be more beneficial to state it as a 
context type and imply some 

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

Comments inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: Monday, January 22, 2018 11:54 AM
To: Bertz, Lyle T [CTO] ; Marco Liebsch 

Cc: dmm@ietf.org
Subject: Re: Parent versus child mobility context

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how to 
organize the information in the model.  So, for that purpose, please verify 
whether my following understandings are correct.

- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a single 
mobile node.

- The DPN uses it to manage data-plane traffic for that mobile node.

>> This may be too broad of a view. What about a mobile node with multiple 
>> mobility sessions? In such a case it may be managing one or more (but not 
>> necessarily all of) the mobile node's mobility sessions

- Your description seems to imply that there are separate mobility contexts for 
each mobility session (i.e., for each bearer, or flow) that terminates (or 
originates) on the mobile node.

>> Yes.

In my earlier email on this subject, I was using Mobility Context as describing 
something more associated with a mobile node, than with a particular flow.  If 
you want it to mean "bearer", then we ought to call it a Bearer.

Maybe it would be easier to understand if we had something called a 
"Mobile-Node Context", and in that context we had a set of Bearer Contexts (or, 
just Bearers).  Each bearer would inherit from the Mobile Node context simply 
by being part of it.  The Mobile Node context (serving as "parent") would 
determine max bandwidth, IP address, etc. Back in the old days, we also defined 
security aspects and some other factors, as part of what FPC would call the 
"mobility context".

>> We have several concepts that have hierarchy, e.g. Service Level (sr-id or 
>> APN - apn-oi if I recall), device level, Mobility Session, bearers, flow 
>> based filters (effectively living within a bearer).   We also have the 5G 
>> concepts as well.  The one thing that is obvious is that the idea of 
>> hierarchy applies whether it is pacers/shapers, bearers or filters that 
>> apply some charging / gating / marking.  A light touch of lifecycle (fate 
>> sharing) amongst the hierarchy,  data does not need to be repeated within 
>> the hierarchy and building the data structure by requiring a parent id if it 
>> was a child (implying the parent must exist!) was the best we could do 
>> without necessarily making decisions that may appear to preclude a specific 
>> set of mobile network technologies. 

If you really want to maintain Parent Context and Child Context as independent 
structure elements, then we need to make a new indexed set for them.


>> We just used a pointer from a Context to a Parent Context. If the value was 
>> non-empty it was a child and the parent Id must point to a valid Context.

Regards,
Charlie P.


On 1/22/2018 5:30 AM, Bertz, Lyle T [CTO] wrote:
> ++ mailing list
>
> I agree with you Marco.
>
> Keeping the parent/child relation is crucial.   Although we often cite 
> dedicated vs. default bearers (LTE) we need to also ack that we use 
> hierarchical concepts throughout mobility and forwarding management 
> protocols, e.g. meters, session and sub-session (includes accounting), etc.
>
> Lifecycle association here (fate sharing of the children with the parent) is 
> an important concept.  Many of the mobility systems assume gateways (LMAs and 
> MAGs) have knowledge of the relationships between sessions and sub-session 
> and will often kill the session in order to reduce signaling overhead.  They 
> also assume when installing a session / sub-session that any violation of 
> hierarchy rules, e.g. setting a child's max bit rate above a parent's, would 
> be properly enforced, i.e. it is an error or the child's value is ignored.
>
> For FPC we also use it to avoid sending redundant data (does one need 
> to send the mobile's IP address for any sort of sub-session work if it 
> is tied to a parent that already has it?)
>
> -Original Message-
> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
> Sent: Monday, January 22, 2018 5:49 AM
> To: Charlie Perkins ; Bertz, Lyle T 
> [CTO] 
> Cc: Satoru Matsushima ; Sri Gundavelli 
> (sgundave) ; Moses, Danny ; 
> Weaver, Farni [CTO] ; Matsushima Satoru 
> 
> Subject: RE: Parent versus child mobility context
>
> That has been introduced to reflect e.g. dedicated bearers which come on top 
> of default bearers hence have some level of dependency. If context associated 
> with a default bearer gets closed, dependent context will follow. To me it 
> makes sense. Others?
>
> marco
>
> -Original Message-
> 

Re: [DMM] Parent versus child mobility context

[Charlie Perkins]

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how 
to organize the information in the model.  So, for that purpose, please 
verify whether my following understandings are correct.


- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a 
single mobile node.


- The DPN uses it to manage data-plane traffic for that mobile node.

- Your description seems to imply that there are separate mobility 
contexts for each mobility session (i.e., for each bearer, or flow) that 
terminates (or originates) on the mobile node.


In my earlier email on this subject, I was using Mobility Context as 
describing something more associated with a mobile node, than with a 
particular flow.  If you want it to mean "bearer", then we ought to call 
it a Bearer.


Maybe it would be easier to understand if we had something called a 
"Mobile-Node Context", and in that context we had a set of Bearer 
Contexts (or, just Bearers).  Each bearer would inherit from the Mobile 
Node context simply by being part of it.  The Mobile Node context 
(serving as "parent") would determine max bandwidth, IP address, etc.  
Back in the old days, we also defined security aspects and some other 
factors, as part of what FPC would call the "mobility context".


If you really want to maintain Parent Context and Child Context as 
independent structure elements, then we need to make a new indexed set 
for them.


Regards,
Charlie P.


On 1/22/2018 5:30 AM, Bertz, Lyle T [CTO] wrote:

++ mailing list

I agree with you Marco.

Keeping the parent/child relation is crucial.   Although we often cite 
dedicated vs. default bearers (LTE) we need to also ack that we use 
hierarchical concepts throughout mobility and forwarding management protocols, 
e.g. meters, session and sub-session (includes accounting), etc.

Lifecycle association here (fate sharing of the children with the parent) is an 
important concept.  Many of the mobility systems assume gateways (LMAs and 
MAGs) have knowledge of the relationships between sessions and sub-session and 
will often kill the session in order to reduce signaling overhead.  They also 
assume when installing a session / sub-session that any violation of hierarchy 
rules, e.g. setting a child's max bit rate above a parent's, would be properly 
enforced, i.e. it is an error or the child's value is ignored.

For FPC we also use it to avoid sending redundant data (does one need to send 
the mobile's IP address for any sort of sub-session work if it is tied to a 
parent that already has it?)

-Original Message-
From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins ; Bertz, Lyle T [CTO] 

Cc: Satoru Matsushima ; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 
Subject: RE: Parent versus child mobility context

That has been introduced to reflect e.g. dedicated bearers which come on top of 
default bearers hence have some level of dependency. If context associated with 
a default bearer gets closed, dependent context will follow. To me it makes 
sense. Others?

marco

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Montag, 22. Januar 2018 06:29
To: Bertz, Lyle T [CTO]
Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave); Moses, Danny; 
Weaver, Farni [CTO]; Matsushima Satoru
Subject: Parent versus child mobility context


Hello folks,

I have looked at this several times, and I would like to propose simplifying it 
to simply be a mobility context.  I don't see that the extra complication is 
worth it, especially right now.  If, in the future, we need it for something, 
we could put it back in.

Thanks for your consideration of this request.

Regards,
Charlie P.



This e-mail may contain Sprint proprietary information intended for the sole 
use of the recipient(s). Any use by others is prohibited. If you are not the 
intended recipient, please contact the sender and delete all copies of the 
message.


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

++ mailing list

I agree with you Marco.

Keeping the parent/child relation is crucial.   Although we often cite 
dedicated vs. default bearers (LTE) we need to also ack that we use 
hierarchical concepts throughout mobility and forwarding management protocols, 
e.g. meters, session and sub-session (includes accounting), etc.

Lifecycle association here (fate sharing of the children with the parent) is an 
important concept.  Many of the mobility systems assume gateways (LMAs and 
MAGs) have knowledge of the relationships between sessions and sub-session and 
will often kill the session in order to reduce signaling overhead.  They also 
assume when installing a session / sub-session that any violation of hierarchy 
rules, e.g. setting a child's max bit rate above a parent's, would be properly 
enforced, i.e. it is an error or the child's value is ignored.

For FPC we also use it to avoid sending redundant data (does one need to send 
the mobile's IP address for any sort of sub-session work if it is tied to a 
parent that already has it?)

-Original Message-
From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins ; Bertz, Lyle T [CTO] 

Cc: Satoru Matsushima ; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 

Subject: RE: Parent versus child mobility context

That has been introduced to reflect e.g. dedicated bearers which come on top of 
default bearers hence have some level of dependency. If context associated with 
a default bearer gets closed, dependent context will follow. To me it makes 
sense. Others?

marco

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Montag, 22. Januar 2018 06:29
To: Bertz, Lyle T [CTO]
Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave); Moses, Danny; 
Weaver, Farni [CTO]; Matsushima Satoru
Subject: Parent versus child mobility context


Hello folks,

I have looked at this several times, and I would like to propose simplifying it 
to simply be a mobility context.  I don't see that the extra complication is 
worth it, especially right now.  If, in the future, we need it for something, 
we could put it back in.

Thanks for your consideration of this request.

Regards,
Charlie P.



This e-mail may contain Sprint proprietary information intended for the sole 
use of the recipient(s). Any use by others is prohibited. If you are not the 
intended recipient, please contact the sender and delete all copies of the 
message.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm