Re: 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
>
>