Subject: [multimob] comments for draft-contreras-multimob-rams-03

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 08 Nov 2011 16:29:47 +0900 (JST)

Hi,

I have reviewed draft-contreras-multimob-rams-03 and have some
comments.

In this draft the authors propose "proactive" handover and "reactive"
handover, but it was difficult to understand the benefit of the
extension for reactive handover, or how the proposed reactive handover
accelerates handover.

Regarding the reactive handover, sect.4.2.1 says;
  "After receiving the PBU message from the nMAG, the LMA will take the
   decision of interrogating or not the pMAG regarding any existing
   multicast subscription for that MN.
   Once the multicast subscription information is retrieved from the
   pMAG, the LMA encapsulates it in the PBA message by using the TLV
   option "Active Multicast Subscription", and forwards the PBA message
   to the nMAG. Then, the nMAG can subscribe the multicast flow on
   behalf of the MN, if there is no other MN receiving it already at the
   nMAG."
However, the reactive handover explained in section 4 requires
exchanging many messages and complex procedures, and I cannot find the
big advantage of providing such extension.

In fact, when we tune Startup Query Interval to a shorter period (see
sect.4.4 in draft-ietf-multimob-igmp-mld-tuning-02.txt), nMAG scarcely
triggers MLD general query and obtains the current state record from
the MN when the MN attaches to the new PtoP link. This is simple and
does not require LMA's involvement.
Moreover, the proposed reactive handover requires new messages called
"Subscription Query" and "Subscription Response". But usually the
procedures to recognize multicast subscription status are done by the
standard MLD and we don't need these new messages if we use the
regular MLD.

Other comment.
For both proactive and reactive handover, "Active Multicast
Subscription" option is used with PBU/PBA.
But this option format is not congruent with RFC3810. A multicast
record must include filter more and must be capable of including
multiple source addresses for one group record. (If you ignore the
exclude filter mode operations, you must explicitly say so and provide
the procedure how you ignore the explicit filter mode operations.)
Null source address must be also allowed.
Although I didn't know the fact, our PMIPv6 extension draft includes
similar message extension. You may want to refer the format in PBU-M
and PBA-M proposed in our PMIPv6 extension draft.

And at last, the name of "RAMS" may not be appropriate, as RAMS is
already well known as Unicast-Based Rapid Acquisition of Multicast RTP
Sessions (RFC6285) and some of AVT drafts have been using this term.

Regards,
--
Hitoshi Asaeda

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 10 Nov 2011 21:49:34 +0100

Hi Hitoshi,

thank you very much for your comments, and apologies for my late response.

I try to answer your comments in line:

2011/11/8 Hitoshi Asaeda <[email-masked]>

> extension for reactive handover, or how the proposed reactive handover

The comparisson has to be done with the reactive case in RFC6224.There the
nMAG is aware of the entering MN subscription once it receives the MLD
Report from the MN, as a reply of the MLD Query sent by the nMAG once the
link was set up.

The time considered in the MLD Query transfer in the radio link (including
framing, radio access delay, ...), plus the time taken by the MN to process
and answer the MLD Query (conditioned by the Query Response interval), plus
the MLD Report going back through the radio channel to the nMAG, is higher
than the time taken on asking the pMAG, which maintains the multicast
subscription of the MN because we are in the reactive case.

We have try to model this in the following paper:
http://isyou.info/jowua/papers/jowua-v2n2-5.pdf

The savings due to RAMS apply not only to RFC6224, but to any other
solution which could depend on the answer of the MN to the MLD Query sent
by the nMAG.

> big advantage of providing such extension.

Let me explain in few words. Two are the processes involved:

1/ When an MN maintains an active subscription, a flag is maintained in the
LMA indicating that (it is not relevant the channel subscribed, because
this is dynimic; it is only relevant that the MN has an active subscription)

2/ When the MN moves to a new access network, as consequence of the
registration process at the nMAG, the LMA checks the flag, and in case the
flag is set, it request to the pMAG the subscription information (IP
addresses of the source and the multicast group) to be passed to the nMAG,
completing the registration. (In case th flag is not set up, meaning that
there is no active subscription, the registration process is done as in
RFC5213)

Hopefully now is better understood.

> does not require LMA's involvement.

As I mentioned above, there are a number of delay sources affecting such
procedure. Furthermore, such delay depends on the underlying radio
technology (wifi, 3gpp, LTE), so no uniform customer experience could be
expected. If you avoid the wireless-related procedures, you eliminate both
problems.

> standard MLD and we don't need these new messages if we use the

This is applicable only by the MAG where the MN is attached, but it suffers
from the problems declared above.

> and PBA-M proposed in our PMIPv6 extension draft.

Thanks for pointin out this fact (I was not aware of). I will check
accodingly.

> Sessions (RFC6285) and some of AVT drafts have been using this term.

Thanks again for rising this. We will modify it to avoid any confussion.

Best regards,
Luis

>
> Regards,
> --
> Hitoshi Asaeda
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 11 Nov 2011 19:23:21 +0900 (JST)

Hi Luis,

Thank you for your reply.
Can I continue the discussion a little more?

> Report from the MN, as a reply of the MLD Query sent by the nMAG once the

MLD Query is *not always* triggered by MLD Report. It depends on the
Report type and the state maintained by the router.
But it is not the point of our current discussion, so skip this.

> http://isyou.info/jowua/papers/jowua-v2n2-5.pdf

I took a look at this paper.
Comparing with Fig.7 (proactive) and 8 (reactive), the time difference
is with "Tacq". The time for reactive handover always adds Tacq time
to the one for proactive handover, hence it's always longer, isn't it?

> solution which could depend on the answer of the MN to the MLD Query sent

Maybe. But my question is, in what kind of situation (or what is the
use case that) your reactive handover is useful, or faster than
proactive handover?

> this is dynimic; it is only relevant that the MN has an active subscription)

I may not understand this.
Whenever MN subscribes some channels, pMAG sends DeReg PBU including
the subscription information (*) to LMA, and LMA transfers it to nMAG
via PBA including the subscription information (*). Then nMAG operates
to forward data to the MN if needed.
Why another "active" flag and message transmission is needed?

(*) This message extension is needed. In my PMIPv6 extension draft,
PBU-M and PBA-M are defined for each.

> there is no active subscription, the registration process is done as in

Whether the MN subscribes some channel or not, LMA gets DeReg PBU.
If DeReg PBU includes MN's subscription info, LMA does not need to
newly ask the MN's subscription information.
Why additional message for transmitting the subscription info must be
defined?

> Hopefully now is better understood.

I think I understand the procedure you defined. But I don't understand
why your reactive handover procedure should be defined as well as the
proactive handover.
Is there any technical reason? Or there is some configuration or
policy requirement I missed?

Regards,
--
Hitoshi Asaeda