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

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.

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

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.

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.

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. 

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, 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.

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

How about the following

   REQ2:  Network-layer mobility support ONLY when needed
 
          DMM solutions MUST NOT provide network-layer mobility support
          when NOT needed.

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

          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.

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