Re: [multimob] AD review of draft-ietf-multimob-igmp-mld-tuning

[Hitoshi Asaeda <[e-mail]>]

Hi Jari,

Thank you for your review.

> Thanks for writing the draft, I think it provides solid advice. There
> are a couple issues in the draft but I have decided to send the draft
> forward for an IETF last call. But I would appreciate a quick response
> of my issues and if necessary, a draft update this week.

I got it.
Please read the following comments and tell us whether our changes are
Ok for you.
We will submit the revised draft soon just after we receive your reply.

> A couple of comments below:
> 
>> Therefore, in this document it is RECOMMENDED that adjacent upstream
>>     multicast routers enable the explicit tracking function for IP
>>     multicast communications on wireless and mobile networks, if they
>>     have enough resources.
> 
> But draft-ietf-pim-explicit-tracking is an informational reference. I
> think you should loosen the language above (maybe "it is recommended
> ...") unless you want to introduce a normative reference and possible
> wait until the other document is approved as an RFC.

We will change "RECOMMENDED" to "recommended".

>>     This document proposes 150 seconds for the [Query Interval] value by
>>     changing the Querier's Query Interval Code (QQIC) field specified in
>>     the IGMP/MLD Query message, for the case that a router enabling the
>>     explicit tracking function sends General Query and potentially
>>     operates a large number of member hosts such as more than 200 hosts
>>     on the wireless link.  This longer interval value contributes to
>>     minimizing traffic of Report messages and battery power consumption
>>     for mobile hosts.
>>
>>     On the other hand, this document also proposes 60 to 90 seconds for
>>     the [Query Interval] value for the case that a router enabling the
>>     explicit tracking function attaches to a wireless link having higher
>>     capacity of the resource.  This shorter interval contributes to quick
>>     synchronization of the membership information tracked by the router
>>     but MAY consume battery power of mobile hosts.
> 
> I had some trouble parsing the recommendations here. Are you
> recommending 150 seconds when explicit tracking is in use? Or only
> when there are > 200 hosts?

Thank you for pointing out.
It should be changed to;
  "This document proposes 150 seconds for the [Query Interval] value
  by changing the Querier's Query Interval Code (QQIC) field specified
  in the IGMP/MLD Query message, for the case that a router enables
  the explicit tracking function and potentially operates a large
  number of member hosts such as more than 200 hosts on the wireless
  link."

> And in the second paragraph, what do you
> mean by "having higher capacity of the resource"? What resource? Did
> you just mean to say "... a wireless link with higher capacity"?

It should be; "a router enabling the explicit tracking function
attaches to a wireless link with higher capacity".

>>     a gradual manner until it exceeds the mobile host's lifetime.
> 
> Perhaps you meant mobile host's binding lifetime? :-) Or some MLD
> lifetime value in the hosts? And what do you do if the various mobile
> hosts have different lifetimes?

Well, this discussion may need more text, while the detail discussion
is not the target of this draft, because it depends on mobile
protocols.
Hence I'll change the paragraph to;

  "In situations where Mobile IPv6 [8] is used, when the home agent
  implements multicast router functionality and multicast data packets
  are tunneled to and from the home agent, the home agent MAY want to
  slow down Query periodicity. It happens, for example, when the home
  agent detects network congestion. In this case, the home agent
  starts forwarding queries with the default [Query Interval] value
  and increases the value in a gradual manner.

Or do you think it is better to just remove this whole paragraph as it
is not congruent to this draft?

>> For a router
>>     that attaches to a wireless link having higher capacity of the
>>     resource or reliable condition
> 
> Just say "having higher capacity or is known to be reliable".

Thanks. Done.

>>     When a receiver host connects directly through a wireless link to a
>>     foreign access router or a home router, the tuning of the IGMP/MLD
>>     protocol parameters SHOULD be the same as suggested in the previous
>>     sections.  The example of this scenario occurs when route
>>     optimization is adopted in MIPv6 [8
>>     <http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-04#ref-8>]
>>     or Mobile IP [11
>>     <http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-04#ref-11>],
>>     or when in
>>     Proxy Mobile IPv6 (PMIPv6) [7
>>     <http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-04#ref-7>],
>>     the mobile access gateway, whose role
>>     is similar to the one of a foreign router, acts as a multicast
>>     router.
> 
> I do not understand what route optimization has to do with this, given
> that it does not support multicast... Suggest deleting the route
> optimization part and just leaving the PMIP part of the last sentence.

Will do. Thanks.

>> between host and home router is used to exchange IGMP/MLD messages
>>     such as [8
>>     <http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-04#ref-8>][11].
> 
> ... such as in [8][11].

Done.

>>     This document assumes that both multicast routers and mobile hosts
>>     MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are
>>     the full or lightweight version.  And this document does not consider
>>     interoperability with older version protocols.  The main reason not
>>     being interoperable with older IGMP/MLD protocols is that the
>>     explicit tracking function does not work properly with older IGMP/MLD
>>     protocols.
> 
> 
> Please expand this a bit. Explicit tracking in the routers does not
> work well when older IGMP/MLD versions are in the hosts? How
> widespread are those older implementations? Can you provide some
> further advice?

Older IGMP/MLD protocols have a report suppression mechanism. It means
older hosts do not respond their report when they hear reports having
the same record.

We will change the above sentense with the following sentense.

  "One of the reasons not being interoperable with older IGMP/MLD
  protocols is that the explicit tracking function does not work
  properly with older IGMP/MLD protocols because of a report
  suppression mechanism; a host would not send a pending IGMP/MLD
  report if a similar report was sent by another listener on the link."

Again, thank you for your review.

Regards,
--
Hitoshi Asaeda