Subject: [multimob] draft-ietf-multimob-igmp-mld-tuning-01.txt

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 Oct 2011 11:13:55 -0500

Hello all,
  The message below was sent on Sept. 15. Since then we have not received
any reviews.
This mail is a call to Multimob and all potential presenters in IETF 82 to
please take some time and make a review of our WG draft. Remember Multimob
is not just for pushing your own draft. We need reviews of WG drafts.
Certainly we need reviews of potential WG drafts as well.

Call to action!

Behcet

Hello Mboned Folks,
  In Multimob we have a WG draft on tuning MLD-IGMP in mobile environments.
Can you please take some time and review this document and give us some good
feedback?
You can post your review on either or both Mboned and Multimob lists.

Regards,

Behcet

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 27 Oct 2011 11:10:21 +0200

Hi all,

Please find below a number of comments regarding
draft-ietf-multimob-igmp-mld-tuning-01.

Comment #1.- In chapter 1 (Introduction), on the first paragraph you state
the following: "However, wireless access technologies operate on a shared
medium or a point-to-point link with limited frequency and bandwidth." The
word "frequency"  in the sentence is not appropriate, in my opinion. I think
it is more adequate to talk about "spectral capacity" or simply "spectrum".

Comment #2.- In chapter 1 (Introduction), on the first paragraph you state
the following: "Slow multicast service activation following a join may incur
additional delay in receiving multicast packets and degrade reception
quality". Instead of the term "reception quality" in my opinion, it would be
more adequate to talk about "quality perception", because the reception
could be good (from the signal point of view) but the quality poor (from the
content point of view).

Comment #3.- In chapter 1 (Introduction), on the second paragraph you state
the following: "For example, when bi-directional tunnel is used with the
mobility entities described in [14][11] in place, the mobile host
experiences additional latency, because the round-trip time using
bi-directional tunnel between mobility entities is larger comparing to the
case that a host and an upstream router attach to a LAN."

However, the case of PMIPv6 described in ref [11] in your draft is a little
bit special. Due that the MAG is a MLD proxy, in case of the content
demanded by the MN is already demanded by another MN attached to the MAG,
the biderectional tunnel does not participate on the latency perceived by
the mobile, because the content is already available on MAG; but the MN
could yet experiencing long delay (due to radio issues, for instance).

Comment #4.- In chapter 1 (Introduction), on the third paragraph you quote
two sentences but there is not reference to the source where the sentences
come from.

Comment #5.-  In chapter 3 (Explicit tracking), on the third paragraph you
mention: "Enabling the explicit tracking function is advantageous for mobile
multicast, but the function requires additional processing capability and a
possibly large memory for routers to keep all membership status." In the
PMIPv6 case, the point-to-point nature of the link seems to simplify this.
Due that the MAG will maintain the multicast status refered to the p-t-p
link, it seems easy to check the subscription of a certain MN just checking
the multicast status of the associated link. So, there are not strong
requirements on it. Could you confirm this assumption?

Comment #6.- In chapter 3 (Explicit tracking), on the third paragraph you
mention: "Therefore, in this document, we propose that adjacent upstream
multicast routers SHOULD enable the explicit tracking function...". It is
not clear to me if you are referring here to the MAG or to the LMA. When I
read this sentence I think on the LMA. But, if so, I don't know why the LMA
should maintain an explicit tracking of thier downstream interfaces, because
the LMA has only the vision of the MLD proxies (MAGs), not the vision of the
end users.

Comment #7.- Regarding the general query interval, you propose in some case
a timer higher than the default (150s instead of 125). If the MAG asks the
MN every 150s, but the LMA is asking the MAG each 125s, we are wasting
resources at MAG. This assymetry is not good from my point of view. I would
suggest to align the LMA-MAG query interval to the highest value of the
MAG-MN timer.Take into account that the variability in the multicast
channels subscription among LMA and MAG will be less than the one among MAG
and MN.

Comment #8.- In section 4.2 (Tuning the MLD Query response interval), you
differientate values for wireless links according to their characteristics.
One value is assigned to lossy links. However, for every kind of link, when
the MN moves and it makes a handover, the link will be necessarily lossy
because the MN is at the border of a cell, probably with not optimial
conditions. Additionally, as the MN moves, the wireless link characteristics
can changed from good to bad. So, do you suggest to dynamically change this
parameter as function of transmission properties, or situations (HO vs
no-HO) as stated at the end of section 4.6?

Comment#9.- In section 4.4 (Tuning Startup Query interval), you mention:
"The default value is 1/4 of [Query Interval]". I would include the value in
seconds for completeness.

Comment#10.- About the Startup Query interval behavior in the base solution:
in RFC 6224 two MLD Queries are triggered, one by the kernel, once the MN is
attaches and the p-tp link is up, and one by the MLD proxy instance
associated by the MAG for that MN. Due that the MN will answer one of them
(either the one of the kernel or the one of the instance), what would be the
behavior for the other one? Should either the kernel or the instance
re-sending the General Query as much times as determined by the startup
query interval?

Comment #11.- In Appendix A, second paragraph you talk about unicast
queries. I think that this is not a great advantage for PMIPv6 because of
the p-t-p nature of the link (only one MN wil be queried either by unicas or
multicast). Maybe this could be clarified in the text.

Comment #12.- In Appendix A, at the end of the page you put in
brackets:"(See Appendix A <#appendix-A> for the detail)" This should be
deleted, I guess.

Best regards,

Luis

2011/10/25 Behcet Sarikaya <[email-masked]>

> Can you please take some time and review this document and give us some
> good feedback?
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 31 Oct 2011 15:00:39 +0900 (JST)

Hi Luis,

Thank you for your comments.

> it is more adequate to talk about "spectral capacity" or simply "spectrum".

Ok, we'll change to "spectrum".

> could be good (from the signal point of view) but the quality poor (from the

I assume you are saying "playback quality", but improving playback
quality is not the target of this draft. I think "reception quality"
is hence appropriate.

> could yet experiencing long delay (due to radio issues, for instance).

The paragraph mentions that the consideration of long delay due to
the tunnel link condition, not a radio link.

I don't think a bad radio condition will give long delay of IGMP/MLD
message transmission. Doesn't it just drop the message?

> two sentences but there is not reference to the source where the sentences

Right, I remove this.

> requirements on it. Could you confirm this assumption?

This draft does not only focus on PMIPv6. As its title, it's for
"Mobile and Wireless Networks".
Furthermore, even with PMIPv6, p-t-p link does not give any
information about multicast membership status. The explicit tracking
function is the suitable way to do it.

I'll mention that this draft also covers non-PMIPv6 in the paragraphs
that include ambiguities.

> the LMA has only the vision of the MLD proxies (MAGs), not the vision of the

This sentence does not mention whether "adjacent upstream multicast
routers" are LMA or MAG. It is a general discussion that the explicit
tracking function is advantageous to reduce the number of transmitted
IGMP/MLD messages when adjacent upstream multicast routers evable it.
According to your assumption, LMA is a router and MAG is a proxy. Even
in this case, if both LMA and MAG enable the function, they less
transmit IGMP/MLD *-specific query messages.

BTW, I admit "SHOULD" is too strong here. I replace it to "recommend".

> channels subscription among LMA and MAG will be less than the one among MAG

I will consider this point. Thanks.

> no-HO) as stated at the end of section 4.6?

This draft does not include such dynamic coordination as it requires
protocol changes, which is not our target.
This draft is a guideline for the protocol tuning; it is difficult to
define the precise or perfect value when the link is changed to a good
or bad condition. I expect that operators will be able to tune the
values by referring this document.

> seconds for completeness.

[Query Interval] is variable value. This draft however recommends 1
second regardless of its value.

> re-sending the General Query as much times as determined by the startup

I cannot understand this. What does "one by the kernel, and one by the
MLD proxy instance" mean? Kernel does not trigger MLD general query.

> multicast). Maybe this could be clarified in the text.

This draft is not only for PMIPv6.

> brackets:"(See Appendix A <#appendix-A> for the detail)" This should be

Done.

Regards,
--
Hitoshi Asaeda