Subject: [multimob] PMIP MC handover -- some thoughts

From: Marco Liebsch <[email-masked]>
Date: Wed, 7 Sep 2011 15:50:28 +0000

Hi,

based on some discussion about multicast handover optimization during IETF81
in Quebec, I have been asked to send some thoughts to the list to foster
the discussion in this context. Please find below some quick thoughts and
questions which I write down. You may take them into account for the
PMIP MC handover discussion. Hope some of them make sense and are useful.
marco

- Why FHO-like forwarding between MAGs is beneficial for multicast?
  It puts assumptions on inter-MAG operation and introduces overhead which
  should be justified.

- Does performance really benefit from forwarding? What's a typical use case:
  Video broadcast, for example. Streaming applications may have some
  buffered packets on the player. How does packet drop during handover
  impact QoE compared to FHO-like forwarded MC packets? I guess they
  have to be buffered at the target MAG before they can be delivered to
  the MN, so latency is introduced whereas only packet drop is reduced.

- Is packet re-ordering an issue (forwarded packets between MAGs vs direct
  packets)? Well, RTP may help on the player if it's used. Or is re-ordering
  resolved on the MAG by means of scheduled delivery to the MN?

- Maybe CTX of multicast context is sufficient. Proactive CTX may help.
  Whereas the benefit of reactive CTX needs to be compared against the
  performance of the Multimob base approach for PMIPv6

- If forwarding between MAGs is adopted, we may consider it optional

- If forwarding between MAGs is not really beneficial, what is the right way for CTX?
  2 approaches are being discussed: inter-MAG CTX (as per RFC4067) and
  CTX via LMA. Can we assume efficient paths between MAGs in operator
  networks? CTX via LMA puts less assumptions on SAs between MAGs and
  link characteristics between MAGs. In particular beneficial when LMA
  stores some multicast context.

---

From: <[email-masked]>
Date: Thu, 22 Sep 2011 18:54:57 +0200

Hi Marco,

thanks for your appreciated thoughts and please excuse the long silence!
I think you are perfectly right that any additional effort due to messages and interfaces between e.g. MAGs have to be evaluated vs. the gain in terms of packet drop during handover - and whether the application scenario really improves by buffering.
I agree that especially for live video broadcast the introduced latency will make integrity of fully delivered packets senseless. However the scenario of a multicast download of videofiles for later viewing could gain from that approach (perhaps is live viewing during movement not the typical application, at least for the driver :-)).

The question of degree of HO delay improvement in different CTX scenarios very much depends on the topology as was already stressed at Quebec meeting. I did some rough estimations for inter-MAG CTX and MAG-LMA CTX (aka RAMS) compared to base multimob approach for the different scenarios:

MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for current 3G topologies with large delays in the core, but allowing for inter-MAG shortcuts):

Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX  < reactive RAMS

MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for current 3G topologies with large delays in the core w/o inter-MAG shortcuts):

Delay/loss rate: base Multimob, proactive RAMS < reactive RAMS < inter-MAG CTX

MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs communicate vie LMA):

Delay/loss rate: base Multimob > RAMS > inter-MAG CTX

Whereas in all cases the total additional signalling load is largest for inter-MAG CTX, whereas the load on radio access (MN-MAG) is largest for base Multimob.

Do you think the assumptions above make sense?
I am currently preparing a paper on those considerations - and will share  results once they are stable for comments and suggestions.

Concerning whether efficient paths between MAGs in operator networks can be assumed IMO it depends: Whereas a direct interconnection (X2) between eNodeBs in E-UTRAN can be assumed, MAGs may be also implemented further up in the network (with even more probable direct links?) ...

I also agree with the existing MAG-LMA association and think a buffering at LMA could be more beneficial (serving even more potential receivers with intermediate outage ...). I think Carlos also agreed to that feature ...

Let's stay in discussion.

Thanks!

Best regards

Dirk

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Marco Liebsch
Gesendet: Mittwoch, 7. September 2011 17:50
An: [email-masked]
Betreff: [multimob] PMIP MC handover -- some thoughts

Hi,

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 22 Sep 2011 23:07:47 +0200

Hi Marco,

thanks for picking this up: Context transfer in MULTIMOB should actually 
converge once in a while, we are discussing this since a long time.

 From the general perspective, context transfer is an optimization and 
not the base/minimal handover solution (like in unicast). Multimob is 
currently scheduled to do optimizations.

Coming to your points, please see answers inline.

> It puts assumptions on inter-MAG operation and introduces overhead which

There are two assumptions here:

  1. There is sufficient mutual trust relationship between MAGs to allow 
CTX/forwarding (typically an intra provider scenario).

  2. The shortest routing distance between pMAG and nMAG is direct 
routing (i.e., the triangle inequality holds - typically true within a 
provider network).

Under these assumptions, FHO-like forwarding is the fastest way of data 
continuity. This is the justification.

> the MN, so latency is introduced whereas only packet drop is reduced.

For the video broadcast, FHO-like forwarding will reduce/diminish packet 
loss in the presence of buffering (as you said). I consider this an 
advantage over the base solution, where - depending on the signaling 
delay to LMA - packets may go bust.

I don't understand your latency argument: Buffering at the nMAG will 
happen only until the MN has arrived and submitted its MLD report. This 
is the minimal HO delay, so no extra latency is introduced.

As for other use cases: Conferencing, gaming, stock tickers (all very 
delay sensitive!) ...

> packets)? Well, RTP may help on the player if it’s used. Or is re-ordering

Reordering must be acceptable by the app. for UDP data - still it is not 
desirable. However, UDP-based apps always need to regain order if they 
need it (e.g., by RTP).

When comparing the two handover approaches (base vers. FHO-like) you 
count loss against possible reordering.

> performance of the Multimob base approach for PMIPv6

I see two answers:

  * CTX-transfer (when aligned with unicast like in the FHO-type) 
without forwarding is as good as the topology supports it. It is very 
easy to come up with all type of results (depending on various routing 
distances that need to be traversed for signaling). It seems like a good 
idea to add a "cookbook-type of evaluation" in the appendix to evaluate 
the benefit of forwarding. We should add this.

* CTX-transfer without unicast alignment can lead to all sorts of weird 
results, one of which steering traffic to the wrong MAG in repeated 
handovers as was raised by Marshall in the last meeting.

> - If forwarding between MAGs is adopted, we may consider it optional
Yes, good point -> this should go along well with the "cookbook-type of 
evaluation".

> stores some multicast context.

This comes back to the initial assumptions:

  1. If pMAG and nMAG both have a trust relation to the same LMA, it may 
be reasonable to assume a corresponding inter-MAG trust relation.

  2. MAGs are access routers in a provider network ... they should allow 
for a direct routing on the shortest available path. Btw., for the core 
argument it does not really matter whether this path is "the most direct 
connection we can think of". All it says is "the shortest path from pMAG 
to nMAG" (and thats where the traffic has to move).

Coming back to the CTX via LMA: This should not only always be the 
longer/slower way, but from my understanding the LMA is a very central 
entity concerned with very many MAGs / MNs. Managing the CTX via the LMA 
puts an additional burden onto this box (multiplied by thousands of 
customers), which much easier could be handled by the (less loaded) 
MAGs. This also is closer to the general paradigm of the Internet - 
where the intelligence sits at the edges, leaving the core with simple 
duties.

So long,

Thomas

-- 

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: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 22 Sep 2011 23:59:30 +0200

Hi Dirk,

to start first with the last: We would be very interested to see your 
preliminary evaluation paper and discuss results.

Some more comments inline:

On 22.09.2011 18:54, [email-masked] wrote:

> The question of degree of HO delay improvement in different CTX
> scenarios very much depends on the topology as was already stressed at
> Quebec meeting. I did some rough estimations for inter-MAG CTX and
> MAG-LMA CTX (aka RAMS) compared to base multimob approach for the
> different scenarios:
> MN-MAG delay << MAG-MAG delay < MAG-LMA delay (as may be typical for
> current 3G topologies with large delays in the core, but allowing for
> inter-MAG shortcuts):

This assumption sounds reasonable to me.

> Delay/loss rate: base Multimob, proactive RAMS < inter-MAG CTX <
> reactiveRAMS

Delay/loss rate looks like an odd metric to me. What shall we think of a 
network that experiences zero delay, but little to infinite loss? What 
is 0/0 then?

> MN-MAG delay << MAG-LMA delay < MAG-MAG delay (as may be typical for
> current 3G topologies with large delays in the core w/o inter-MAG
> shortcuts):

More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG 
delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always hold.

> MN/MAG delay > MAG-MAG delay > MAG-LMA delay (as could be achieved in
> future LTE/EPC topologies without direct inter-MAG connection, i.e. MAGs
> communicate vie LMA):

???? I'm not an LTE expert, but as far as I know, the wireless link 
delay in LTE is small. I read "downlink below 1 ms". If true, this 
assumption seems artificial.

> Do you think the assumptions above make sense?

As said, some of them do, some don't.

> Concerning whether efficient paths between MAGs in operator networks can
> be assumed IMO it depends: Whereas a direct interconnection (X2) between
> eNodeBs in E-UTRAN can be assumed, MAGs may be also implemented further
> up in the network (with even more probable direct links?) ...

MAGs need to be the first hop routers, so below the MAG its all L2. 
Personally, the worst network I can think of builds a star topology 
starting from LMA - still some meshing in larger provider networks seems 
appropriate. But you'll never know - some people sell wireless access 
cables on Ebay.

> I also agree with the existing MAG-LMA association and think a buffering
> at LMA could be more beneficial (serving even more potential receivers
> with intermediate outage ...). I think Carlos also agreed to that
> feature ...

Buffering on the LMA means buffering in the core network. This carries 
the (misleading) charm that the same packets could be replayed to 
different MAGs/MNs. However, this is not that simple, as MNs do not 
behave in a synchronized fashion. Even if subscribed to the same group, 
each MN performs its handover at a different position in the packet 
flow. So the LMA would need to keep track of that (for MN X select 
packets Y-Z from group buffer G_X).

My counter picture would see the LMA keeping individual buffers for 
thousands of MNs ... which looks like a case for Avici. Unfortunately, 
Avici is gone.

Best wishes,

Thomas

> ------------------------------------------------------------------------
> *Von:* [email-masked] [mailto:[email-masked]] *Im
> Auftrag von *Marco Liebsch
> *Gesendet:* Mittwoch, 7. September 2011 17:50
> *An:* [email-masked]
> *Betreff:* [multimob] PMIP MC handover -- some thoughts
>
> Hi,
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

--

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 27 Sep 2011 11:24:49 +0200

Hi Dirk,

Some comments below.

********

-----
[Luis>>] For this first scenario, I wonder what RTT measurements are you considering for establishing that in current 3G networks MN-MAG delay is below the delays you can find in the MAG-MAG or MAG-LMA communication. I think this is hard to achieve, even for LTE, if we consider no ideal conditions in the radio part.
Regarding the estimation you do, I have some considerations. First at all, regarding base solution vs proactive RAMS, base multimob solution has to account for the MLD Query/Report delays, while RAMS certainly not, because the subscription information or multicast context is piggybacked in the de-registration messages. So, in my opinion, base multimob solution performs always worst, except if we assume that MLD process takes 0 ms (both message transmission as well as message processing).
Respect to the comparison between FHO and reactive RAMS, if MAG-MAG delay < MAG-LMA delay, I think that you comparison holds only in the case of CTX transfer for predictive FHO, not in the case of multicast traffic forwarding, because in such case you need additional MLD Query/Report messages from nMAG to pMAG, thus adding more delay, nor in the case of reactive FHO, because in such case FHO  depends on the radio part, introducing the delays required for framing, and the delays required for solving the MLD process with the MN.
-----

----
[Luis>>] I think this comparison holds in the same terms as above regarding proactive RAMS and base solution.
----

----
[Luis>>] I don't understand well this comparison. If MAG-MAG delay > MAG-LMA delay, then RAMS performs always better than FHO. Do you agree?
----

----
[Luis>>] Well, FHO also relays in radio mechanisms to report new point of attachment, so FHO also generates load at radio level.
----

----
[Luis>>] Direct links can be useful in scenarios where the MAG-MAG communication can be offloaded from the data network. Could be the support of FHO for multicast the justification for this? I'm not totally sure, at least not as a general case (neither for unicast case). In my opinion, an architecture without such shortcuts will be more common. But it is only my vision.
----

Thanks!

Best regards

Dirk

----
[Luis>>] Best regards,
Luis
----

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 27 Sep 2011 12:30:03 +0200

Hi Thomas,

Please, find some comments below.

---------- Forwarded message ----------
From: Thomas C. Schmidt <[email-masked]<mailto:[email-masked]>>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: Marco Liebsch <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

 1. There is sufficient mutual trust relationship between MAGs to allow CTX/forwarding (typically an intra provider scenario).

 2. The shortest routing distance between pMAG and nMAG is direct routing (i.e., the triangle inequality holds - typically true within a provider network).

----
[Luis>>] Furthermore, both MAGs need to support FHO, and the MNs need to transfer information relative to nMAG ID in case of predictive HO
Additionally, you need implement in nMAG a mechanism able to buffer multicast traffic forwarded from pMAG together with multicast traffic directly arriving to nMAG for those groups not forwarded, and feeded by two distinct MLD proxy instances (the one pointing the LMA, and the one pointing the pMAG)
----

Under these assumptions, FHO-like forwarding is the fastest way of data continuity. This is the justification.

- Does performance really benefit from forwarding? What's a typical use
case:

For the video broadcast, FHO-like forwarding will reduce/diminish packet loss in the presence of buffering (as you said). I consider this an advantage over the base solution, where - depending on the signaling delay to LMA - packets may go bust.

I don't understand your latency argument: Buffering at the nMAG will happen only until the MN has arrived and submitted its MLD report. This is the minimal HO delay, so no extra latency is introduced.

----
[Luis>>] I think that in reactive case the latency incurred by the FHO mechanism is not negligible. First, before triggering the FHO mechanism, you need to obtain the subscription information directly from the MN, and afterwards the nMAG have to trigger the FHO process. Before receiving the multicast flow forwarded by the pMAG, it is necessary to interexchange 4 messages, the HI/HACK couple and the MLD Query/Report pair. In the meanwhile, the nMAG has already triggered the subscription to the groups subscribed by the MN recently attached. So, if you want to serve both the forwarded traffic from pMAG and direct traffic arriving nMAG, you need some kind of buffering, at either MN or nMAG, to play out the multicast traffic conveniently, and this imposes some latency.
----

I see two answers:

 * CTX-transfer (when aligned with unicast like in the FHO-type) without forwarding is as good as the topology supports it. It is very easy to come up with all type of results (depending on various routing distances that need to be traversed for signaling). It seems like a good idea to add a "cookbook-type of evaluation" in the appendix to evaluate the benefit of forwarding. We should add this.

* CTX-transfer without unicast alignment can lead to all sorts of weird results, one of which steering traffic to the wrong MAG in repeated handovers as was raised by Marshall in the last meeting.

----
[Luis>>] But FHO certainly decouples multicast from unicast when it is established that in case of HI/HACK messages for unicast have been already sent, new ones are sent for multicast. In my understanding this way of decoupling makes independent the unicast and the multicast HO. Of course they share a common way of transferring the information, a common syntax, but they are not tightly coupled.
----

- If forwarding between MAGs is not really beneficial, what is the right
way for CTX?

 1. If pMAG and nMAG both have a trust relation to the same LMA, it may be reasonable to assume a corresponding inter-MAG trust relation.

 2. MAGs are access routers in a provider network ... they should allow for a direct routing on the shortest available path. Btw., for the core argument it does not really matter whether this path is "the most direct connection we can think of". All it says is "the shortest path from pMAG to nMAG" (and thats where the traffic has to move).

Coming back to the CTX via LMA: This should not only always be the longer/slower way, but from my understanding the LMA is a very central entity concerned with very many MAGs / MNs. Managing the CTX via the LMA puts an additional burden onto this box (multiplied by thousands of customers), which much easier could be handled by the (less loaded) MAGs. This also is closer to the general paradigm of the Internet - where the intelligence sits at the edges, leaving the core with simple duties.

----
[Luis>>]There are ways to do that in a light way. We think RAMS proposal, for instance, does not impose too much to the LMA.
----

So long,

Thomas

----
[Luis>>] Regards,
Luis
----

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 27 Sep 2011 12:41:31 +0200

Hi Thomas,

Please, find some comments inline.

---------- Forwarded message ----------
From: Thomas C. Schmidt <[email-masked]<mailto:[email-masked]>>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always hold.

----
[Luis>>] I don't think so. In case of proactive RAMS HO, the pMAG-LMA and LMA-nMAG flows are part of the registration process, so no additional messages are needed.
In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO optimization process, but LMA-nMAG messages are part of the registration process.
In case of FHO, you need the HI/HACK messages, the MLD Query/Report messages for forwarding, and the LMA-nMAG messages for registering.
So, in the best case, (no multicast forwarding) FHO and RAMS HO have the same number of messages flowing across the network.
The different delay can be obtained from the paths among MAGs, or between LMA-MAG, not from the number of messages involved in the process.
Don't forget the dependency of the radio part for some of the cases.
----

???? I'm not an LTE expert, but as far as I know, the wireless link delay in LTE is small. I read "downlink below 1 ms". If true, this assumption seems artificial.

----
[Luis>>] Despite the radio access delay due to framing, we have to take into account the MLD processing by the MN, as well as no ideal conditions in the radio part (we are in a HO process where the MN is in the border of a cell, so it is hard to consider ideal conditions)
----

[Luis>>] Best regards,
Luis

---

From: <[email-masked]>
Date: Tue, 27 Sep 2011 14:02:42 +0200

Hi Thomas,
Thanks for your immediate response ... And for your interest in our work - it is still in first steps as you may have detected from the assumptions which partly may be very artificial ... We are working on that. And we will let you know asap ;-)
Please see my other comments inline

Thank you and best regards
Dirk

Von: Thomas C. Schmidt [mailto:[email-masked]]
Gesendet: Freitag, 23. September 2011 00:00
An: von Hugo, Dirk
Cc: [email-masked]; [email-masked]
Betreff: Re: [multimob] PMIP MC handover -- some thoughts

Hi Dirk,

= Dirk: Sorry for my mistyping (quick typing before thinking) - what I meant here was 'delay' _or_ (as it may be proportional) 'loss ratio' (rather than loss rate).

= Dirk: That's what I meant with MAG-MAG > MAG-LMA, i.e. in worst case inter-MAG communication is via LMA (or some entity which is nearer to LMA than to MAG). But since some messages are exchanged between nMAG and LMA, some between pMAG and LMA and (for some approaches) some directly between nMAG and pMAG I decided to split nMAG-LMA-pMAG into both parts ...

= Dirk: I just heard something about 3.5 ms between UE and eNodeB - but the main assumption was that wired links in core could be very fast thanks to still higher bandwidth (e.g. fibre)
And assuming heterogeneous networks with WLAN completing LTE the wireless delay may be larger due to multiple hops to MAG and processing for e.g. CSMA and so on.

= Dirk: You are right - this needs more elaboration (the explicit tracking is on MAG, I assume).

Best wishes,

Thomas

= Dirk: Thanks a lot again!

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Sep 2011 17:19:57 -0500

Hi all,
  Sorry but I don't see anything in this mail relevant to what Marco posted
(in the subject line), like:

Why FHO-like forwarding between MAGs is beneficial for multicast?
Does performance really benefit from forwarding?
Is packet re-ordering an issue (forwarded packets between MAGs vs direct
  packets)? Or is re-ordering
  resolved on the MAG by means of scheduled delivery to the MN?
Maybe CTX of multicast context is sufficient. Proactive CTX may help.
  Whereas the benefit of reactive CTX needs to be compared against the
  performance of the Multimob base approach for PMIPv6
If forwarding between MAGs is not really beneficial, what is the right way
for CTX?

Regards,

Behcet
On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO
<[email-masked]>wrote:

>  Hi Thomas,****
>
> ** **
>
> Please, find some comments inline.****
>
> ** **
>
> ** **
>
> From: *Thomas C. Schmidt* <[email-masked]>
> Date: 2011/9/22
> To: [email-masked]
> Cc: [email-masked]
>
>
>
> ****
>
>  ** **
>
> shortcuts):****
> ** **
> More precisely, you should compare pMAG-LMA-nMAG delay to pMAG-nMAG delay
> ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always hold.****
>
> * *
>
> *----*
>
> *[Luis>>] I don’t think so. In case of proactive RAMS HO, the pMAG-LMA and
> LMA-nMAG flows are part of the registration process, so no additional
> messages are needed.*
>
> *In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO
> optimization process, but LMA-nMAG messages are part of the registration
> process.*
>
> *In case of FHO, you need the HI/HACK messages, the MLD Query/Report
> messages for forwarding, and the LMA-nMAG messages for registering. *
>
> *So, in the best case, (no multicast forwarding) FHO and RAMS HO have the
> same number of messages flowing across the network. *
>
> *The different delay can be obtained from the paths among MAGs, or between
> LMA-MAG, not from the number of messages involved in the process.*
>
> *Don’t forget the dependency of the radio part for some of the cases.*
>
> *----*****
>
> ** **
>
> communicate vie LMA):****
>
> ** **
>
> ???? I'm not an LTE expert, but as far as I know, the wireless link delay
> in LTE is small. I read "downlink below 1 ms". If true, this assumption
> seems artificial.****
>
> * *
>
> *----*
>
> *[Luis>>] Despite the radio access delay due to framing, we have to take
> into account the MLD processing by the MN, as well as no ideal conditions in
> the radio part (we are in a HO process where the MN is in the border of a
> cell, so it is hard to consider ideal conditions)*
>
> *----*****
>
> ** **
>
>  ** **
>
> *[Luis>>] Best regards,*
>
> *Luis*****
>
> ------------------------------
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 28 Sep 2011 02:07:45 +0200

Hi Behcet, hi Luis,

On 28.09.2011 00:19, Behcet Sarikaya wrote:

>    Sorry but I don't see anything in this mail relevant to what Marco
> posted (in the subject line), like:
>

This is probably true ... anyway, please see answers inline.

> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Thomas,____
>
>     __ __
>
>     Please, find some comments inline.____
>
>     __ __
>
>     __ __
>
>     From: *Thomas C. Schmidt* <[email-masked]
>     <mailto:[email-masked]>>
>     Date: 2011/9/22
>     To: [email-masked] <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>
>
>
>
>     ____
>
>         __ __
>
>         shortcuts):____
>     __ __
>     delay ... and "pMAG-nMAG delay =< pMAG-LMA-nMAG delay" should always
>     hold.____
>
>     */__ __/*
>
>     */----____/*
>
>     */[Luis>>] I don’t think so. In case of proactive RAMS HO, the
>     pMAG-LMA and LMA-nMAG flows are part of the registration process, so
>     no additional messages are needed.____/*
>

Well, you need to signal the HO - if this happens a priory (in a 
predictive mode), then re-directions happens asynchronously, possibly in 
parallel to the Phy handover. This is the same in FHO. If RAMs anchors 
signaling at the LMA, then signaling is either pMAG-LMA-nMAG or 
nMAG-LMA-nMAG, both being of the same delay magnitude.

>     */----/*____
>         __ __
>         communicate vie LMA):____
>
>     __ __
>
>     assumption seems artificial.____
>
>     */__ __/*
>
>     */----____/*
>
>     */[Luis>>] Despite the radio access delay due to framing, we have to
>     take into account the MLD processing by the MN, as well as no ideal
>     conditions in the radio part (we are in a HO process where the MN is
>     in the border of a cell, so it is hard to consider ideal
>     conditions)____/*
>
>     */----/*____
>

For the radio, I guess we can assume normal behavior which is only 
slightly slower than a normal 100 Mbit LAN link.

For the MLD processing: in FHO we don't have an MLD processing at MN in 
the normal predictive mode and no signaling on the wireless link. So 
these possible issues don't apply. In the reactive mode, one could do 
without the MN-local MLD processing ... this is only applied for the 
sake of acceleration.

The key comparison is not the wireless link, but the routing distances 
pMAG/pAR <-> nMAG/nAR versus MAG <-> LMA ... in addition of course FHO 
is not bound to PMIP.

Best regards,

Thomas

-- 

° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany

---

From: <[email-masked]>
Date: Wed, 28 Sep 2011 14:43:11 +0200

Hi Behcet,
referring to your comment of course not all issues raised by Marco (e.g. re-ordering) are covered but I see at least the following points:

FHO-like forwarding between MAGs includes CTX initiation - and we might evaluate whether or for which scenarios (topologies,i.e. delays on different paths _and/or_ applications, i.e. real-time or full content delivery) there are benefits compared to LMA-MAG based forwarding.
 And regarding the benefit of Proactive CTX and Reactive CTX compared to Base Multimob: This should be focus of some calculations described earlier which of course need refinements ...
... and questions of delay on radio part or between MAGs/LMAs and the required messages there are driving the delay and thus the performance IMHO.
Or what is the point which I missed?

Best regards
Dirk
________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Mittwoch, 28. September 2011 00:20
An: LUIS MIGUEL CONTRERAS MURILLO
Cc: [email-masked]; [email-masked]
Betreff: Re: [multimob] PMIP MC handover -- some thoughts

Hi all,
  Sorry but I don't see anything in this mail relevant to what Marco posted (in the subject line), like:

If forwarding between MAGs is not really beneficial, what is the right way for CTX?

Regards,

Behcet
On Tue, Sep 27, 2011 at 5:41 AM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,

---------- Forwarded message ----------
From: Thomas C. Schmidt <[email-masked]<mailto:[email-masked]>>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

----

----

[Luis>>] Best regards,
Luis

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_______________________________________________
multimob mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multimob

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 29 Sep 2011 09:32:04 +0200

Hi Behcet,

find my opinion below.

Regards,

Luis

________________________________
De: Behcet Sarikaya [[email-masked]]
Enviado el: miércoles, 28 de septiembre de 2011 0:19
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]; [email-masked]
Asunto: Re: [multimob] PMIP MC handover -- some thoughts

Hi all,

Why FHO-like forwarding between MAGs is beneficial for multicast?
[Luis>>] The multicast content forwarding can be beneficial for either strict-real time services or networks with long handover time
Does performance really benefit from forwarding?
[Luis>>] In the situations above the forwarding can mitigate the service disruption, so the performance (QoE) can be improved
Is packet re-ordering an issue (forwarded packets between MAGs vs direct
  packets)? Or is re-ordering
  resolved on the MAG by means of scheduled delivery to the MN?
[Luis>>] There will be probably buffering at both MAG and MN (some dejittering buffer), so reordering would be done probably in both points
Maybe CTX of multicast context is sufficient. Proactive CTX may help.
  Whereas the benefit of reactive CTX needs to be compared against the
  performance of the Multimob base approach for PMIPv6
[Luis>>] I think there are two dimensions: one is the way the subscription information is knowledge by the MAG, and the other one is the multicast traffic forwarding. The first one is strictly necessary to optimize the handover, while the other helps to imporve it. As you proposed, it makes sense to implement it as an option, because not all the application take benefit of it, so an operator can skip it, looking for a more easy to manage access network.
If forwarding between MAGs is not really beneficial, what is the right way for CTX?
[Luis>>] In my opinion you have already provided the way: context transfer (i.e., multicast subscription info) as mandatory, multicast traffic forwarding as an option.

Regards,

Behcet

---------- Forwarded message ----------
From: Thomas C. Schmidt <[email-masked]<mailto:[email-masked]>>
Date: 2011/9/22
Subject: Re: [multimob] PMIP MC handover -- some thoughts
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

----
[Luis>>] I don’t think so. In case of proactive RAMS HO, the pMAG-LMA and LMA-nMAG flows are part of the registration process, so no additional messages are needed.
In case of reactive RAMS HO, the pMAG-LMA messages are specific of the HO optimization process, but LMA-nMAG messages are part of the registration process.
In case of FHO, you need the HI/HACK messages, the MLD Query/Report messages for forwarding, and the LMA-nMAG messages for registering.
So, in the best case, (no multicast forwarding) FHO and RAMS HO have the same number of messages flowing across the network.
The different delay can be obtained from the paths among MAGs, or between LMA-MAG, not from the number of messages involved in the process.
Don’t forget the dependency of the radio part for some of the cases.
----

----

[Luis>>] Best regards,
Luis

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 29 Sep 2011 09:55:20 +0200

Hi Thomas,

some additional comments (I'm not sure if I understand correctly your comments)

Best regards,

Luis

________________________________________

[Luis>>] What I mean is that the HO in proactive RAMS is embedded in the de-registration process, so no additional messages are there. The info is piggybacked.

[Luis>>] But the MAGs needs to know what are the channels the MN is subscribed to before asking for them to the pMAG, so you are forced to wait for the MLD Report coming from the MN, otherwise the MAG even does nto know if the MN has any active subscription (you don't have the multicast context at nMAG, so, what can the nMAG request to the pMAG?)

[Luis>>] I don't think so by reason above, for sure in the case of reactive HO.

Best regards,

Thomas

--