Re: AD Evaluation: draft-ietf-dmm-requirements

Le 28/01/2014 19:58, h chan a écrit :
> Let me try to understand the concern here.
>
> What is new in this requirement is "when needed" in contrast to
> providing IP mobility by default.

First, providing mobility by default is not a black/white alternative to
not providing mobility.

It is very possible on the same machine to have Mobile IP enabled for
some flows and disabled for others (depending what we call a 'flow'). 
It is also possible to have Mobile IP and NAT at the same time on the 
same Mobile Router.

> Without this requirement, mobility support may be provided by
> default, which is transparent to higher layers.

Again, transparency to higher layers means we talk mobility management
on a Mobile Host.

Transparency to higher layers has little meaning if we talk mobility
management provided on a Mobile Router (which is not a Mobile Host).

> With this requirement, assume there are separate steps in the DMM
> solution. 1. A decision is made whether network-layer mobility
> support is needed. 2. When the need is established, network-layer
> mobility support is invoked. 3. Then transparent support is provided
>  and is transparent to layers above IP.
>
> Transparency is clear in step 3 above.

This looks like a trigger which enables mobility, or other times
disables it.

But one can have a Mobile IP daemon and a NAT run at the same time on
the same machine.  There is no decision in time.

Some decision happens at packet based on IP destination address.

> The question however is whether the preceding steps involve the
> application, so that one may question whether the entire DMM solution
> (with all the steps) as a whole is transparent.

I agree.  I am not aware of any application which talks to Mobile IP. 
Whenever it is there it is 'transparent'.

> So the intention of the requirement is that WHEN/AFTER the decision
> is made to invoke mobility support, then the mobility support is
> transparent to the application. Then we may want to check and make
> sure the emphasis of this requirement does mean transparency in this
>  respect only.

I disagree.

As I said above, the word 'transparency' is dubious.  Some times it may 
mean 'non-existent', some times it may mean light goes through it but 
modified.

If one wants to continue using it, then one should better qualify it
with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'.

Because a Mobile Router doing mobility management in a transparent
manner on the Mobile Router for the LFN has nothing to do with
applications, neither with upper layers.

Also, a Mobile Router doing NAT and Mobile IP at the same time is
50%-transparent.

>
> Original wording:
>
> REQ2:  Transparency to Upper Layers when needed
>
> DMM solutions MUST provide transparent mobility support above the IP
>  layer when needed.  Such transparency is needed, for example, when,
                    ^on a Mobile Host.
> upon change of point of attachment to the network, an application
> flow cannot cope with a change in the IP address.

(it's not the application flow, it is a socket which some times may
break [paste here the error from the screen]; the term 'application 
flow' in this context has little meaning)

(an 'application flow' has no understandable meaning in practice).

> However, it is not always necessary to maintain a stable home IP
> address or prefix for every application or at all times for a mobile
> node.
       ^a Mobile Host.

I agree.

> I now tend to think the first sentence in this original wording may
> steer the emphasis on providing transparent support, which is not
> what the motivation and the problems are talking about.

I agree.

> The motivation and the problems are talking about when they are not
> needed. The emphasis of this requirement therefore is on the
> capability to turn OFF unnecessary mobility support.

In a sense I agree with the meaning.

But when trying to turn off or on mobility support the things are not 
like if there were a knob on/off, not even like starting/stopping some 
daemon.  It is a matter of always having the Mobile IP support on, and 
tweak the routing table with some particular entries, and the 
firewalling rules to NAT some addresses or not.

> How about the following
>
> REQ2:  Network-layer mobility support ONLY when needed

If we understood better when it was needed...

> DMM solutions MUST NOT provide network-layer mobility support when
> NOT needed.

I would say that Mobile IP MUST always be turned on on a Mobile Host.

> (or if you don't like double negatives: (DMM solutions MUST provide
> network-layer mobility support ONLY when needed)

No, I would say to have it always on.  If some applications don't want 
it then dont use it; realize that by inserting routing table entries.

One may wonder when some applications dont want it.  One answer is when 
some applications prefer to not go through the HA in order to take 
advantage of the 4G pure speed.  When? For example if the HA link is too 
slow compared to 4G.  (remark this is not the same as saying that the 
triangular route is longer than straight, because that is always true).

This is not a request for Route Optimization.  It is an invitation to 
analyze in deeper detail the application needs.

One may have an application start via the HA (offer reachability) and 
continue straight, w/o HA.  It's the same application.

Consider a video-call like appli: you want to be reachable always at the 
same IP address (through HA) but once the session is ongoing you may not 
want to use it through HA if no handover in sight.

Something like that.

These things could be further refined if we really went into detail and 
understood what are the needs of applications, the distinctions MH-MR, etc.

> Such transparent mobility support above the IP layer is needed, for
> example, when, upon change of point of attachment to the network, an
>  application flow cannot cope with a change in the IP address.
> However, it is not always necessary to maintain a stable home IP
> address or prefix for every application or at all times for a mobile
>  node.

A Mobile Host never maintains a stable prefix, only a stable address.

A Mobile Router may maintain a stable address (its HoA) and may maintain 
a stable prefix  (its MNP).  It could also just maintain stable just its 
MNP, but not its HoA; and vice-versa.  Is that mobility?

For each of these there is an application :-)

Alex

>
> Any comments/changes/corrections?
>
> H Anthony Chan
>
> -----Original Message----- From: dmm [mailto:[email protected]] On
> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM
> To: [email protected] Subject: Re: [DMM] AD Evaluation:
> draft-ietf-dmm-requirements
>
> Le 28/01/2014 02:45, h chan a écrit :
>> I will drop "related"
>>
>> Regarding the following
>>
>> 5. Section 5: - I am a little confused by REQ2.  It says that a DMM
>> solution should be transparent to the applications.
>
> This remark is typically true when we talk Mobile IP on a Mobile Host
> and an application like firefox runs above a BSD Socket interface.
>
>
>> However, the motivation talks about identifying applications that
>> do (or do not) need mobility support from the network layer.  That
>>  doesn't sound transparent to me.  Am I reading this incorrectly?
>>
>> It appears that unless the network can find out whether the
>> application has need of such support, the application indeed may
>> need to invoke mobility support or has to convey its need to the
>> network.
>>
>> The emphasis of requirement is on "when needed." So, I think it is
>>  better to drop the word "transparent" as follows:
>>
>> REQ2:  Mobility support when needed
>>
>> DMM solutions MUST provide mobility support to above the IP layer
>> when needed.  Such support is needed, for example, when, upon
>> change of point of attachment to the network, an application flow
>> cannot cope with a change in the IP address.  However, it is not
>> always necessary to maintain a stable home IP address or prefix for
>> every application or at all times for a mobile node.
>>
>> Motivation: The motivation of this requirement is to enable more
>> efficient routing and more efficient use of network resources by
>> selecting an IP address or prefix according to whether mobility
>> support is needed and by not maintaining context at the mobility
>> anchor when there is no such need.
>
> Whenever we discuss this 'transparency' paragraph I have again the
> same comments.
>
> First, I am not sure DMM is only about Mobile Hosts, or about Mobile
> Routers as well.
>
> Because, if we talk Mobile Routers, then rarely an application runs
> directly on it.  Most applications would run on LFN.
>
> Transparency?
>
> If the applications run on the LFN, the change of the attachment of
> the MR is 'transparent' to them, regardless whether or not MR does
> something to maintain stability of that address (Mobile IP, other).
>
> Second, this transparency may depend on the direction, or more
> complex 'shape' of the application flows.  Some IP flows of some
> applications have very complex 'shapes', with various sets of IP src
>  and dst, and triangular or HA-less shapes.
>
> Take for example a video-call.  The session establishment through an
> intermediary and behind NAT is followed by the ongoing 4 flows (2
> audio 2 video)... they all take different paths... each may need or
> not need to go through the HA, and each has distinct behaviours when
>  the IP address changes, hence each would have a distinct
> 'transparency' requirement.  Is this _one_ application?
>
> Alex
>
>>
>> H Anthony Chan
>>
>> -----Original Message----- From: dmm [mailto:[email protected]]
>>  On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20
>> AM To: h chan; [email protected];
>> [email protected]; Peter McCann Subject: Re: [DMM] AD Evaluation:
>> draft-ietf-dmm-requirements
>>
>>
>>
>> On 1/24/14 7:38 PM, h chan wrote:
>>> 4. Section 4: - I am not sure that it benefits the document to
>>> label PS6 and PS7 as related.  Those issues are problematic on
>>> their own. If you remove the "(related problem)" label from them,
>>> make sure that REQ2 is updated to remove mention of "related
>>> problem".
>>>
>>> The intention of the name "related problems" was not to suggest
>>> they are less problematic, but rather to distinguish them from
>>> the other problems directly on mobility management. Although
>>> these problems are not directly on mobility management, the DMM
>>> solutions can solve these additional problems. They are therefore
>>> included. So, as long as this section is not to be interpreted as
>>> limited to problems directly on mobility management, we can drop
>>> the word "related."
>>>
>>
>> I will leave it to the authors/WG, but I don't see a benefit to the
>> "related" tag.
>>
>> Regards, Brian
>>
>> _______________________________________________ dmm mailing list
>> [email protected] https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>
>
> _______________________________________________ dmm mailing list
> [email protected] https://www.ietf.org/mailman/listinfo/dmm
>
>