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

Le 30/01/2014 20:53, h chan a écrit :
> Alex,
>
> I think the applications which work without MIP are the applications
> that can cope with the change of IP address of the MR. Is that
> correct?

Yes, that is correct for MH.

For the MR cases, any application running on the Host can cope with that
change (==TCP retransmits).

> Then mobility support is needed only for those applications that
> cannot cope with the change of IP address of the MR.

No, that is wrong.

IT depends what one means by 'mobility support' - on the MR or in the
network?

MR-based mobility support is needed on the MR for some kinds of
applications on Host to continue working.

Infrastructure-based mobility support is alternatively needed on the MR
for some kinds of applications on Host to continue working.

A mix of infrastructure-based mobility support and MR-based mobility
support is needed for some kinds of applications on Host to continue
working.

The 3 statements are valid simultaneously.

We can't just say that _only_ MR-based mobility support is needed.

> So, in the two separate sentences:
>
>> Mobility Support on a Mobile Host is needed, for example, when a
>> Mobile Host moves and an arbitrary application in the Mobile Host
>> cannot cope with a change in the IP address of that Mobile Host
>> [paste socket error message here].
>
> Is this MN sentence the same as: Mobility support is needed, for
> example, when a mobile host moves and an application cannot cope
> with a change in the IP address of the mobile host.

Right, same.

>> Mobility Support on a Mobile Router is needed, for example, when a
>>  Mobile Router moves together with a set of Hosts and Routers, and
>>  arbitrary applications in the Hosts and Routers need to maintain
>> their IP address fixed regardless of the change of the IP address
>> of the Mobile Router, and the Access Router performs ingress
>> filtering, and reachability of these Hosts and Routers at a fixed
>> IP address is necessary.
>
> When the MR carries a network of hosts and routers, doesn't these
> routers in turn carry network so that at the final level of hosts,
> the applications are running there. If so, is it sufficient to state
> the applications in the hosts? (which includes hosts in the network
> of routers which are in turn in the network of the mobile router)

YEs, it is sufficient.

> So a host in the network of a router, which in turn is in the network
> of another router, which .... in the network of the mobile router can
> be called a host that moves with the mobile router.

YEs.

> Then is the MR sentence the above the same as
>
> Mobility support is also needed, for example, when a mobile router
> moves together and an application in a host that moves with the
                 ^ together with the Host
> mobile router cannot cope with a change of IP address of the mobile
> router.

YEs.

At this point we should say that [infrastructure-based, or MR-based, or 
a mix of the two] mobility support is needed, for example, when a Mobile 
Router moves together with the Host and an application on the latter is 
interrupted by the change of the IP address of the former.

(because we don't want that Host to cope with it; if we say 'can not 
cope' it's like if we wanted it to).

Alex

> REQ2:  Bypassable Network-layer mobility support
>
> DMM solutions MUST enable network-layer mobility but it MUST be
> possible to not use it.
>
> Mobility support is needed, for example, when a mobile host moves
> and an application cannot cope with a change in the IP address.
>
> Mobility support is also needed, for example, when a mobile router
> moves together and an application in a host which moves with the
> mobile router cannot cope with a change of IP address of the mobile
> router.
>
> However mobility support at the network-layer is not always needed;
> a mobile node can often be stationary, and mobility support can also
> be provided at other layers. It is then not always necessary to
> maintain a stable IP address or prefix.
>
> One more alternative is to mention the "no need" case only without
> explaining the "needed" case as in the following. Yet if it is
> possible to state the "needed" case more concisely, it will be more
> clear to spell that out as in above.
>
> REQ2:  Bypassable Network-layer mobility support
>
> DMM solutions MUST enable network-layer mobility but it MUST be
> possible to not use it. Mobility support at the network-layer is not
> always needed; a mobile node can often be stationary, and mobility
> support can also be provided at other layers. It is then not always
> necessary to maintain a stable IP address or prefix.
>
> H Anthony Chan
>
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email protected]] Sent: Thursday, January 30,
> 2014 11:39 AM To: h chan; [email protected] Subject: Re: [DMM] AD
> Evaluation: draft-ietf-dmm-requirements
>
> Le 30/01/2014 18:08, h chan a écrit :
>> Alex,
>>
>> Is the following correct?
>>
>> Mobility support is needed, for example, when a mobile host or a
>> mobile router moves and an application in the mobile host or in a
>> host that moves with the router cannot cope with a change in the
>> IP address of the mobile node.
>
> Makes better sense, thanks.
>
> But still uses that word 'Mobile Node' which is confusing.  How
> about this:
>
>> Mobility support is needed, for example, when a Mobile Host or a
>> Mobile Router moves and an application in the Mobile Host or in a
>> host or router that moves with that Mobile Router cannot cope with
>> a change in the IP address of the mobile host or of that Mobile
>> Router.
>
> It would be more precise.
>
> But even then, it does not hold, because a Host that moves with the
> Mobile Router is not that much influenced by the change of IP
> address of that MR.  When the MR changes its IP address, the Host
> feels it just like some other interruption in the path to another CN.
> These kinds of interruptions (link up/down) happen often in the
> fixed networks and yet Hosts continue to work.
>
> It is possible, for example, to have a Mobile Router move, have NAT
> (not mobility management), change IP address, and the Hosts and
> Routers in that moving network will continue working ok.
>
> It is also possible for MR to not have NAT, and forward packets with
> an address which is not topological correct in that network.  These
> packets will reach their destinations (provided there's no ingress
> filtering), and the replies will not arrive.  Some applications do
> not need packets to return.  One can very well have a vehicle which
> streams the video of its front camera to some particular server in
> the Internet, and change its IP address at each access.  This does
> not require Mobile IP nor NAT.
>
> I think it is impossible to stay meaningful in one phrase talking
> both Mobile Host and Mobile Router at the same time.  I think we
> need maybe two phrases.
>
>> Mobility Support on a Mobile Host is needed, for example, when a
>> Mobile Host moves and an arbitrary application in the Mobile Host
>> cannot cope with a change in the IP address of that Mobile Host
>> [paste socket error message here].
>>
>> Mobility Support on a Mobile Router is needed, for example, when a
>>  Mobile Router moves together with a set of Hosts and Routers, and
>>  arbitrary applications in the Hosts and Routers need to maintain
>> their IP address fixed regardless of the change of the IP address
>> of the Mobile Router, and the Access Router performs ingress
>> filtering, and reachability of these Hosts and Routers at a fixed
>> IP address is necessary.
>
> Alex
>
>>
>> H Anthony Chan
>>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email protected]] Sent: Thursday, January 30,
>> 2014 2:13 AM To: h chan; [email protected] Subject: Re: [DMM] AD
>> Evaluation: draft-ietf-dmm-requirements
>>
>> Le 29/01/2014 20:45, h chan a écrit :
>>> Alex
>>>
>>> How about the following:
>>>
>>> REQ2:  Using and not Using Network-layer mobility support
>>>
>>> DMM solutions MUST enable network-layer mobility
>>>
>>> but it MUST be possible to not invoke it.
>>>
>>> Mobility support is needed, for example,
>>>
>>> when an application (of a MN or a host in a mobile network of a
>>> MR)
>> ^a LFN (because just 'host' may be confused with Mobile Host; and
>> also because within the moving network there is also one or
>> several Routers - not hosts.)
>>
>>> cannot cope with a change in the
>>>
>>> IP address of the mobile node when the node moves.
>> ^Mobile Host or of the Mobile Router moves (because when the 'node'
>> moves it may mean that the 'host' in the moving network moves, and
>> that doesn't change its IP address).
>>
>>> Yet a mobile node can often be stationary,
>>>
>>> and mobility support can also be provided at other layers.
>>>
>>> It is then not always necessary to maintain a
>>>
>>> stable IP address or prefix.
>>>
>>> Can the text in red be valid for both host or router?
>>
>> Yes and no.  I agree with it, but I'd prefer the suggested
>> modifications.
>>
>> Alex
>>
>>>
>>> When the node is a router:
>>>
>>> an application (of a host in a mobile network) may not be able to
>>> cope with a change in the IP address of the MR when the MR
>>> moves.
>>>
>>> When the node is a host
>>>
>>> an application (of a MN) may not be able to cope with a change
>>> in the IP address of the MN when the MN moves.
>>>
>>> H Anthony Chan
>>>
>>> -----Original Message----- From: Alexandru Petrescu
>>> [mailto:[email protected]] Sent: Wednesday, January
>>> 29, 2014 12:30 PM To: h chan; [email protected] Subject: Re: [DMM] AD
>>>  Evaluation: draft-ietf-dmm-requirements
>>>
>>> Le 28/01/2014 23:33, h chan a écrit :
>>>
>>>> Let us try to include MR.
>>>
>>>>
>>>
>>>> How about the following
>>>
>>>>
>>>
>>>> REQ2:  Network-layer mobility support when needed
>>>
>>>>
>>>
>>>> DMM solutions MUST enable network-layer
>>>
>>>> mobility when needed.
>>>
>>>> Such mobility support is needed, for
>>>
>>>> example, when an application or a host cannot cope with a
>>> change in the
>>>
>>>> IP address when a node moves.  However, it is not always
>>> necessary to maintain a
>>>
>>>> stable IP address or prefix.
>>>
>>>>
>>>
>>>> Here, the node can be a mobile host or a mobile router.
>>>
>>> I am not sure the term 'node' is agreed to cover both an MH and
>>> an MR.
>>>
>>> I think in all descriptions it would be clearer if we just said
>>> MH when we meant Mobile Host and MR when we meant Mobile Router.
>>>
>>> Le me paraphrase this text in RFC6275:
>>>
>>>> This document specifies a protocol that allows nodes to remain
>>>
>>>> reachable while moving around in the IPv6 Internet.  Without
>>>> specific
>>>
>>>> support for mobility in IPv6 [6], packets destined to a mobile
>>>> node
>>>
>>>> would not be able to reach it while the mobile node is away
>>>> from its
>>>
>>>> home link.
>>>
>>> There is a clear ambiguity in the 'mobile node' used above.
>>> Because if we talk moving networks then often the packets are
>>> destined (the contents of the destination address) to a LFN, not
>>> to the MR.
>>>
>>> If that 'node' were a Mobile Router (not a Mobile Host) it
>>> completely misses the case when packets are destined to the LFN,
>>> which is not an MH nor an MR.
>>>
>>> The phrase should rather say:
>>>
>>> 'packets destined to a MH (or to a LFN behind a MR) would not be
>>> able
>>>
>>> to reach it while that MH (or the MR and LFN) is away from its
>>> home
>>>
>>> link.'
>>>
>>> This kind if expression would be clearer.
>>>
>>> Alex
>>>
>>> 'packets destined to a [LFN] or to the Mobile Host, or to the
>>> Mobile Router, would not be able to reach it while the Mobile
>>> Router is away from its home link'.
>>>
>>>> A host can be a mobile host or a host in a LFN.
>>>
>>>> An application can be running on a mobile host or a on a host
>>>> in a LFN.
>>>
>>>> A MR also does not need to maintain stable IP address or
>>>> prefix when
>>> there are no hosts attached to it or when there are no active
>>> applications running in the hosts of its network.
>>>
>>>>
>>>
>>>> Any comments/changes/corrections?
>>>
>>>>
>>>
>>>> H Anthony Chan
>>>
>>>>
>>>
>>>>
>>>
>>>> -----Original Message-----
>>>
>>>> From: Alexandru Petrescu [mailto:[email protected]]
>>>
>>>> Sent: Tuesday, January 28, 2014 1:27 PM
>>>
>>>> To: h chan; [email protected] <mailto:[email protected]>
>>>
>>>> Subject: Re: [DMM] 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] <mailto:[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]
>>> <mailto:[email protected]>;
>>>
>>>>>> [email protected] <mailto:[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] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>> _______________________________________________ dmm mailing
>>>>> list
>>>
>>>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>>>
>>>
>>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>
>>
>>
>>
>
>
>
>