Subject: [multimob] Performance analysis paper mentioned during the session

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 25 Jul 2011 17:21:12 +0200

Hi,

For those interested, here is the link of the paper I mention analyzing
the performance of our RAMS proposal:

http://www.jowua.org/index.php/jowua/article/view/66/56

Comments would be more than welcome, of course.

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 25 Jul 2011 18:58:11 -0400 (Eastern Sommerzeit)

Hi Carlos,

  I had a short look at your paper. Your numerical evaluation is based 
on a rough topology model. Overall, you argue that the delay between the 
MN and MAG is larger compared to the delay between MAG and LMA.

  Some comments:

  * The authors of [18] analyzed the time a packet spends in a router. 
This is more related to router modeling instead of path delay modeling. 
From this perspective this seems not the correct modeling step for your 
problem.

  * You assumed that MAG and LMA reside in the same Autonomous System, 
right? This is a valid assumption but must not be true in general. 
Obviously this would change the delay (cf., "An AS-level Study of 
Internet Path Delay Characteristics" GLOBECOM'04). For a more 
well-grounded evaluation you should model the relation between MAG and 
LMA in more detail. This could be interesting.

  * For the backhaul delay you use 5 ms referring to the 3GPP standard. 
I would doubt that this is realistic, in particular compared to the 
LMA-MAG delay. First, the standard cannot define the delay between the 
NodeB and the MAG. Second, the NodeB should be obviously in the 
topological vicinity of the MAG. In other words, if you assume a 
significant large delay between NodeB and MAG but a short delay between 
MAG and LMA, you could 'directly' attach the NodeB to the LMA.

  * The comparison with RFC 6224 seems a bit unfair. It would 
be more interesting to compare with the FMIP proposal, for example.

  Just to make sure that I'm not misunderstood: Your assumption 
(reducing delay because MAG-LMA link is faster) is not uninteresting but 
needs a more careful verification. You need a more detailed radio as 
well as topology model to derive general protocol design insights. In 
particular, you need more detailed information on current MAG/LMA 
deployment within networks.

Best regards
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 19:29:55 -0400

Hi Juan Carlos, Carlos,

  IMO the reasonable comparison in the context transfer routing is

  (i)   pMAG <-> nMAG versus

  (ii)  pMAG <-> LMA <-> nMAG

The corresponding links are all wired and pMAG is adjacent to nMAG.

 From all reasonable topologies I can imagine, (i) should be an order of 
magnitude shorter than (ii).

Cheers,

Thomas

On 25.07.2011 18:58, Matthias Waehlisch wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 26 Jul 2011 21:45:36 +0200

Hi Matthias,

thanks for your comments. This paper tries to be a prospective insight about
the feasability of an internal signalling protocol to acelerate multicast
delivery to a MN after handover. It is based on public references to
establish the potential benefits of this proposal, assuming the best
performace case in some situations (for instance, no MLD response time by
the MN, etc) to highlight that even in such case there is room for
improvement with our proposal. A more precise analysis is however required
to precisely obtain the improvements claimed.

Please, find my answer in your mail:

> From this perspective this seems not the correct modeling step for your

 I assume you refer to reference [21] Papagiannaki et al. You are correct
when stating that it is related to the time spent in one hop of an
operator's network. The missing piece for considering path delay is the
delay contribution due to the transmission part linking the routers of the
operator's network.
As per ITU-T G.114 spec, the contribution due to optical fiber can be
considered to be 5 microseconds per km. That is, a contribution of 1ms
implies a distance of 200 km between both ends. So, the impact of this
contribution is clearly dependant on network size and topology. These two
elements are difficult to handle in a general way.
The topology under consideration in the paper assumes that both MAG and LMA
are closer elements, not distant nodes (i.e., the distance among them is not
as large as 200 km) . This is clearly an hypothesis, and it is based on
current trends observed in real 3G networks, where the location of both SGSN
and GGSN tend to be close for both small networks (entities centralization)
and medium-to.large networks (entities regionalization). We have taken this
hypothesis in our considerations, in such a way that transmission
contribution is negligible.
Even if we center our analysis in a network deployment with extremal
settings, for instance 1000km among MAG and LMA, the total contribution due
to the transmission layer would be around 5 ms. This does not change the
essence of the paper, which highlights a faster communnication internal to
the network regarding to one relaying on the radio part, due to framing and
other radio intrinsic properties which makes wireless part slower than wired
part.

> LMA in more detail. This could be interesting.

You are right, we are considering taht bot MAG and LMA are part of the same
AS. In fact, I think this is the natural setting when talking of multicast
in PMIPv6. You should be aware that IGMP/MLD are multicast membership
protocols, that is, they are protocols among a host part and a router part.
I wonder how a host (MLD proxy in MAG) can inetract with a router (LMA) any
of them being lloacted in different ASs.Normal interdomain multicast is
carried out among routers running some interdomain routing protocol. The
situation of a host and a router in different AS appears to me as the
exception, not as the normal deployment.
Note for instance that an IGMP/MLD report coming from the MAG would be send
with an IP address of a different AS towards the LMA. How the LMA learn such
address? Is there BGP among MAG and LMA? Is there some static route being
advertised through BGP for the tunnel links? Can the LMA reach the MAG IP
address via another way different to the tunnel? (with BGP running among
both ASs I assume yes).
In summary, we assume that both entities are in the same AS. This appears to
us as the natural deployment, at least for multicast service.

> MAG and LMA, you could 'directly' attach the NodeB to the LMA.

I agree that the 3GPP standard can not define the delay. It is only an
indication, a reasonable value to be considered as reference, as the one
also proposed by the NGMN Alliance. We use them because also in this case
the value to be assumed is dependant of network size, topology and
technology. A good survey of backhaul landscape can be found at the paper by
Humai Raza "A Brief Survey of Radio Access Network Backhaul Evolution: Part
I" in the IEEE Communications Magazine of June 2011.
The backhaul networks are generally characterized by a large number of
small/medium sites connected to centralised aggregation points in charge of
concentrating traffic towards the core network. There are several solutions
for such connection from the network architecture point of view (rings,
nested rings, stars, chains, point-to-point, etc). Each of them has a
different impact on the end-to-end delay budget. Several technologies can be
used for backhaul: point-to-point (packet) microwave transmission, optical
fiber, xDSL technologies (such as VDSL), etc. Those different technologies
have distinct particularities in terms of performance, reliability and
delay. All of them typically coexist in a real mobile network, in such a way
that a MN changing the point of attachment can pass smoothly from one
solution to another.
So, we take such value as reference considering it as an average of the
delays that can be found in a real network, from the best case (optic fiber,
<1ms) to the worst case (xDSL, > 10ms). Once again, a hugher or lower value
does not change the essence of the paper, in my opinion.

> be more interesting to compare with the FMIP proposal, for example.
RAMS proposes an improvement regarding the base solution, so that is the
reason of comparing it with the base solution. The comparisson with FPMIPv6
has to be done yet.

> deployment within networks.
I agree that a more powerful characterization is needed, maybe by simulation
or by establishing a reference scenario. As I mentioned before, the aim of
the paper is to be prospectivea bout the benefits of signalling internally
to the network.  We have used reference in the literature to prospect the
interest of this protocol. Now it is time of performing an in depth
characterization, once we conclude that it is interesting to explore this
way to accelerate multicast delivery after handover.

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 26 Jul 2011 21:54:09 +0200

Hi Thomas,

this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <-> LMA <->
nMAG message, but not necessarily if you need more than 1 message in the
pMAG <-> nMAG dialogue.

I think the key point is that you are relaying in L2 capabilities to create
the pMAG <-> nMAG dialogue. But those capabilities are not the general case.
However, the path pMAG <-> LMA <-> nMAG is naturally available,
independently of the L2 capabilities.

Best regards,

Luis

2011/7/26 Thomas C. Schmidt <[email-masked]>

>> ______________________________**_________________
>> multimob mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>>
>
> --
>
> ° http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/~schmidt>   Fax: +49-40-42875-8409 °
> ______________________________**_________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Jul 2011 16:25:32 -0400

Hi Luis,

two answers:

  (i) The network distance is *always* independent of the # of messages.
  (ii) In the (P)FMIP approach, only one message is exchanged for 
unicast (that includes the multicast option). So we actually have "zero" 
messages induced by multicast.

The main point here is: The (P)FMIP draft produces an overall optimized 
handover, for unicast and synchronously for multicast (recall: you 
cannot overtake unicast. If unicast handover is slow, you cannot fix 
this on the multicast side).

Regarding your L2 objection: (P)FMIP uses L2 information to predict the 
nMAG, otherwise it doesn't (remember: you called your approach 
predictive in the absence of a prediction ;) ). The transfer from pMAG 
to nMAG does not depend on special "L2 capabilities" ... this is 
ordinary IP routing which is present in most Inter-Networks ...

Btw.: If you look at current WG activities in Netext 
http://tools.ietf.org/html/draft-ietf-netext-pmip-lr, you'll see that 
inter-MAG routing is used for traffic optimization. So there is not only 
common understanding that MAGs mutually participate in Internet routing, 
but also that the shortest distance from pMAG to nMAG must be expected 
to be the direct route. In a well-designed provider network, direct 
routes *are optimal*. (In the global Internet, this is not always true 
as we know about violations of the triangle inequality, but it is always 
the best guess.)

Returning to the comparison: An approach that uses messaging sent on 
triangular routes cannot be as fast as the directly routed transfer.

Cheers,

Thomas

On 26.07.2011 15:54, Luis M. Contreras wrote:
> Hi Thomas,
> this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <-> LMA
> <-> nMAG message, but not necessarily if you need more than 1 message in
> the pMAG <-> nMAG dialogue.
> I think the key point is that you are relaying in L2 capabilities to
> create the pMAG <-> nMAG dialogue. But those capabilities are not the
> general case. However, the path pMAG <-> LMA <-> nMAG is naturally
> available, independently of the L2 capabilities.
> Best regards,
> Luis
>
>
> 2011/7/26 Thomas C. Schmidt <[email-masked]
> <mailto:[email-masked]>>
>
>     Hi Juan Carlos, Carlos,
>
>      From all reasonable topologies I can imagine, (i) should be an
>     order of magnitude shorter than (ii).
>
>     Cheers,
>
>     Thomas
>
>
>         _________________________________________________
>         multimob mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/multimob
>         <https://www.ietf.org/mailman/listinfo/multimob>
>
>
>     --
>
>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>     +49-40-42875-8409 °
>     _________________________________________________
>     multimob mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/multimob
>     <https://www.ietf.org/mailman/listinfo/multimob>
>
>

--

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 26 Jul 2011 22:49:03 +0200

Hi Thomas,

>   (i) The network distance is *always* independent of the # of messages.

You are quite right on that statement, but the comparison Luis was
making was "1 message pMAG<-->LMA<-->nMAG vs n messages pMAG<-->nMAG" :D

> messages induced by multicast.

Multicast traffic nature should also be analyzed. Is it worth optimizing
that much the performance for traffic that typically is not critical if
one message is lost? Our draft tries to make a simple optimization, by
making information about the subscription interests of the MN as soon as
possible. Nothing more. no strong requirement needed (no security
between MAGs, no FPMIP signalling, etc.).

> this on the multicast side).

Do we need that much complexity for multicast? We may have the scenario
in which the "slow" unicast handover is perfectly fine (we have
prototype implementations with quite low handovers delays in a local
scenario) and still want to optimiza multicast.

> ordinary IP routing which is present in most Inter-Networks ...

Yes, ordinary IP routing, but you assume that there always exist an
shorter route between pMAG and nMAG, which might not be always the case.

> as we know about violations of the triangle inequality, but it is always 

True, though the scope of that draft is not only MAG to MAG
optimizations.

> triangular routes cannot be as fast as the directly routed transfer.

And an approach that requires security associations between every pair
of MAGs is not as simple to deploy as one that doesn't.

Carlos

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Jul 2011 17:04:03 -0400

Hi Luis,

> between MAGs, no FPMIP signalling, etc.).

Yes, I agree: your approach is simpler. However, it does not optimize 
(only slightly improve) the handover.

The question is about the objective. My understanding is (which I 
questioned in the meeting and on the list yesterday) that we aim at 
optimizing mobility management to perform seamless handovers. And the 
answer we are trying to give is: A solution to minimize handover delays 
for unicast + multicast in *one* synchronized operation.

> scenario) and still want to optimiza multicast.

This is a valid question. But if we don't need seamless handover, we can 
stay with the base solution and don't need extra context transfer. (As 
you could extract from the mail of Matthias: taking realistic numbers 
leads to an about equal performance of the base solution and your 
approach).

> shorter route between pMAG and nMAG, which might not be always the case.

As mentioned before: direct routes within a provider network should be 
optimal.

Cheers,

Thomas

>>> this holds if you compare 1 pMAG<->  nMAG message against 1 pMAG<->  LMA
>>> the pMAG<->  nMAG dialogue.
>>> create the pMAG<->  nMAG dialogue. But those capabilities are not the
>>> general case. However, the path pMAG<->  LMA<->  nMAG is naturally
>>> 2011/7/26 Thomas C. Schmidt<[email-masked]
>>>        (i)   pMAG<->  nMAG versus
>>>        (ii)  pMAG<->  LMA<->  nMAG
>>>          [email-masked]<mailto:[email-masked]>
>>>      [email-masked]<mailto:[email-masked]>

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 26 Jul 2011 23:42:23 +0200

Hi Thomas,

some comments below:

>  (i) The network distance is *always* independent of the # of messages.

Totally true. I mean the delay is not only dependant on the network
distance, but on the times such distance is used to transfer the required
information.

>  (ii) In the (P)FMIP approach, only one message is exchanged for unicast
> (that includes the multicast option). So we actually have "zero" messages
> induced by multicast.
>

In a similar scenario, in RAMS the multicast subscription information is
piggybacked in the DeReg (pMAG) - Reg (nMAG) sequence, so no additional
messages are needed. No messages induced by multicast, nor by handover
support. This is applicable for the scenario we call (badly, of course)
predictive case.

> handover, for unicast and synchronously for multicast (recall: you cannot
> overtake unicast. If unicast handover is slow, you cannot fix this on the
> multicast side).
>

I have the multimob charter in mind, where the focus is multicast. Why don't
unicast traffic can suffer an slower delay. It is easier to handle, as well
as less sensitive to delay, in many cases. I think that a faster unicast
handover is desirable, but in my opinion it can not force a solution for
multicast.

> nMAG, otherwise it doesn't (remember: you called your approach predictive in
> the absence of a prediction ;) ). The transfer from pMAG to nMAG does not
> depend on special "L2 capabilities" ... this is ordinary IP routing which is
> present in most Inter-Networks ...
>

Ok, the name "predictive" is not well applied. It is used as the opposite to
the reactive case, but I agree it is not well suited.
I think that the transfer from pMAG to nMAG depends on special capabilities
of L2 because those capabilities have to correctly identify nMAG. If such
identification is not provided by L2, it is not possible to route the
traffic to nMAG. Furthermore, those L2 capabilities will be dependant on the
underlying radio technology. So generalization is not easy.

> http://tools.ietf.org/html/**draft-ietf-netext-pmip-lr<http://tools.ietf.org/html/draft-ietf-netext-pmip-lr>,
> you'll see that inter-MAG routing is used for traffic optimization. So there
> is not only common understanding that MAGs mutually participate in Internet
> routing, but also that the shortest distance from pMAG to nMAG must be
> expected to be the direct route. In a well-designed provider network, direct
> routes *are optimal*. (In the global Internet, this is not always true as we
> know about violations of the triangle inequality, but it is always the best
> guess.)
>

Here the point is the delay employed in finding such optimal routes. Whereas
in a normal communication procedure (such as the one you reference) the time
is not critical, in the handover case it can become an important issue (even
more for multicast case). If we relay in radio dependant procedures, we will
experience a non uniform behavior (it depends on the underlaying radio
technology), besides considering that not all the possible radio
technologies can support the needed mechanisms to implement PFMIP.

> triangular routes cannot be as fast as the directly routed transfer.

The triangular route is intrinsic to the registration procedures defined in
RFC5213. We take profit of that to augment the scope of such procedure to
accelerate the acquisition of the subscription information. Important
aspects such as the security associations (as highlighted by Carlos), the
multicast groups acceptable by the nMAG, the capacity of nMAG to support
multicast, etc resultis in a more lightweigth protocol

Best regards,

Luis

>> 2011/7/26 Thomas C. Schmidt <[email-masked]**hamburg.de<[email-masked]>
>> <mailto:schmidt@informatik.**haw-hamburg.de<[email-masked]>
>> >>
>>
>>
>>    Hi Juan Carlos, Carlos,
>>
>>        ______________________________**___________________
>>        multimob mailing list
>>        https://www.ietf.org/mailman/_**_listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob>
>>        <https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>> >
>>
>>
>>    --
>>
>>    ° http://www.informatik.haw-__**hamburg.de/~schmidt<http://www.informatik.haw-__hamburg.de/%7Eschmidt>
>>    <http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/%7Eschmidt>>
>>    Fax:
>>    +49-40-42875-8409 °
>>    ______________________________**___________________
>>    multimob mailing list
>>    https://www.ietf.org/mailman/_**_listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob>
>>    <https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>> >
>>
>>
>>
> --
>
> ° http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/%7Eschmidt>   Fax: +49-40-42875-8409 °
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Jul 2011 17:56:30 -0400

Hi Luis,

On 26.07.2011 17:42, Luis M. Contreras wrote:

>
>     The main point here is: The (P)FMIP draft produces an overall
>     optimized handover, for unicast and synchronously for multicast
>     (recall: you cannot overtake unicast. If unicast handover is slow,
>     you cannot fix this on the multicast side).
>
>
> I have the multimob charter in mind, where the focus is multicast. Why
> don't unicast traffic can suffer an slower delay. It is easier to
> handle, as well as less sensitive to delay, in many cases. I think that
> a faster unicast handover is desirable, but in my opinion it can not
> force a solution for multicast.
>

Sure, but I'm arguing the other way round: Multicast cannot be better 
than the unicast configuration and seamless handover for multicast can 
only go with seamless unicast handover. For this it makes a lot of sense 
to me to plug into a standardized solution for unicast.

>
>     Regarding your L2 objection: (P)FMIP uses L2 information to predict
>     the nMAG, otherwise it doesn't (remember: you called your approach
>     predictive in the absence of a prediction ;) ). The transfer from
>     pMAG to nMAG does not depend on special "L2 capabilities" ... this
>     is ordinary IP routing which is present in most Inter-Networks ...
>
>
> Ok, the name "predictive" is not well applied. It is used as the
> opposite to the reactive case, but I agree it is not well suited.
> I think that the transfer from pMAG to nMAG depends on special
> capabilities of L2 because those capabilities have to correctly identify
> nMAG. If such identification is not provided by L2, it is not possible
> to route the traffic to nMAG. Furthermore, those L2 capabilities will be
> dependant on the underlying radio technology. So generalization is not easy.
>

You point to the predictive case: (P)FMIP does both, predictive and 
reactive handover. As far as I know, predictions always rely on L2 
information (actually on L1 sensing).

>     http://tools.ietf.org/html/__draft-ietf-netext-pmip-lr
>     <http://tools.ietf.org/html/draft-ietf-netext-pmip-lr>, you'll see
>     that inter-MAG routing is used for traffic optimization. So there is
>     not only common understanding that MAGs mutually participate in
>     Internet routing, but also that the shortest distance from pMAG to
>     nMAG must be expected to be the direct route. In a well-designed
>     provider network, direct routes *are optimal*. (In the global
>     Internet, this is not always true as we know about violations of the
>     triangle inequality, but it is always the best guess.)
>
>
> Here the point is the delay employed in finding such optimal routes.
> Whereas in a normal communication procedure (such as the one you
> reference) the time is not critical, in the handover case it can become
> an important issue (even more for multicast case). If we relay in radio
> dependant procedures, we will experience a non uniform behavior (it
> depends on the underlaying radio technology), besides considering that
> not all the possible radio technologies can support the needed
> mechanisms to implement PFMIP.
>

Which radio technologies do you refer to? (My understanding: you can 
always do radio sensing, even though this may be done at different 
places (MN or base station).

> The triangular route is intrinsic to the registration procedures defined
> in RFC5213. We take profit of that to augment the scope of such
> procedure to accelerate the acquisition of the subscription information.
> Important aspects such as the security associations (as highlighted by
> Carlos), the multicast groups acceptable by the nMAG, the capacity of
> nMAG to support multicast, etc resultis in a more lightweigth protocol
>

Yes, RFC5213 does it the triangular way. That's why I argue that doing 
better requires more than 5213 unicast.

Cheers,

Thomas

>         2011/7/26 Thomas C. Schmidt <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>
>             Hi Juan Carlos, Carlos,
>
>                    I had a short look at your paper. Your numerical
>         evaluation
>                 is based
>                    * The authors of [18] analyzed the time a packet
>         spends in a
>                 router.
>                 This is more related to router modeling instead of path
>         delay
>                 modeling.
>                   From this perspective this seems not the correct
>         modeling step
>                 for your
>                 problem.
>
>                    * You assumed that MAG and LMA reside in the same
>         Autonomous
>                 System,
>                 well-grounded evaluation you should model the relation
>         between
>                 MAG and
>                    * For the backhaul delay you use 5 ms referring to
>         the 3GPP
>                 standard.
>                 significant large delay between NodeB and MAG but a
>         short delay
>                 between
>                 ___________________________________________________
>                 multimob mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         https://www.ietf.org/mailman/____listinfo/multimob
>         <https://www.ietf.org/mailman/__listinfo/multimob>
>         <https://www.ietf.org/mailman/__listinfo/multimob
>         <https://www.ietf.org/mailman/listinfo/multimob>>
>
>
>             --
>
>             ° Hamburg University of Applied Sciences
>         Berliner
>             Tor 7 °
>             ° Dept. Informatik, Internet Technologies Group    20099
>         Hamburg,
>             Germany °
>             ° http://www.informatik.haw-____hamburg.de/~schmidt
>         <http://www.informatik.haw-__hamburg.de/%7Eschmidt>
>         <http://www.informatik.haw-__hamburg.de/~schmidt
>         <http://www.informatik.haw-hamburg.de/%7Eschmidt>>    Fax:
>             +49-40-42875-8409 °
>             ___________________________________________________
>             multimob mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         https://www.ietf.org/mailman/____listinfo/multimob
>         <https://www.ietf.org/mailman/__listinfo/multimob>
>         <https://www.ietf.org/mailman/__listinfo/multimob
>         <https://www.ietf.org/mailman/listinfo/multimob>>
>
>
>
>     --
>
>     <http://www.informatik.haw-hamburg.de/%7Eschmidt>    Fax:
>     +49-40-42875-8409 °
>
>
>
>

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 27 Jul 2011 00:03:51 +0200

Hi Thomas,

some extra comments below

>
>>
>
> Yes, I agree: your approach is simpler. However, it does not optimize (only
> slightly improve) the handover.
>

Well, RAMS provides the multicast subscription information to nMAG at
registration time, once the MN certainly attaches to nMAG. If the MN finally
does not attach the nMAG there is no impact in the network (no extra
signalling, nor tunnels, nor authentication, nor L2 procedures, etc). The
subscription information is obtained without extra signalling when the MN is
firstly de-registrated from pMAG, and only with a pair of messages between
LMA and pMAG in the reactive case. I think it is something better than an
slight improve.

> optimizing mobility management to perform seamless handovers. And the answer
> we are trying to give is: A solution to minimize handover delays for unicast
> + multicast in *one* synchronized operation.
>
>
>
I'm not sure if it is the objective of the Multimob wg, but to optimise
multicast handover. Even in such case, one synchornized operation for both,
your point of view is to adapt unicast-suited procedures to multicast. Maybe
the way is to think on multicast-suited procedures and then to extend them
to unicast. We can not drop any solution for multicast only due that in the
unicast case there is now a solution.

> stay with the base solution and don't need extra context transfer. (As you
> could extract from the mail of Matthias: taking realistic numbers leads to
> an about equal performance of the base solution and your approach).

Sorry, I disagree. Only considering the framing of the radio technology, and
the MLD response time taken by the MN (set to 0 in our paper, being between
0 and 1 s in current vendors operating systems) it is clear that RAMS is
superior.

Best regards,

Luis