Subject: [multimob] Some comments on draft-asaeda-multimob-igmp-mld-optimization-01

From: Stig Venaas <[email-masked]>
Date: Wed, 28 Oct 2009 15:56:43 -0700

I've had a quick read of this draft and have some comments.

1. Lightweight IGMPv3/MLDv2

    There is some discussion on this that I don't think is very
    relevant to multimob. Whether to implement the lightweight or
    regular version is IMO entirely a host stack implementation
    issue. It does not influence PMIP or the network infrastructure.
    At least not as long as we also need to support the regular
    versions. I see benefits with the lightweight mode, but not for
    us.

2. Unsolicited notifications (MLD reports)

    This may be useful, but I think this is a change in protocol. So
    at least with respect to our charter item for a document on tuning
    IGMPv3/MLDv2 I think this goes to far. It is more than just tuning.

3. Unicast of General Queries

    This is interesting and according to MLDv2 specifications, hosts
    MUST respond to these. It would be interesting to verify whether
    implementations generally support this. I think this can be useful,
    but there are also scenarios where I believe multicasting them is
    better. I think this is a change in the protocol, at least from a
    router perspective, so this also goes a bit beyond what we are
    asking for in the charter right now. It could perhaps be optional
    behavior...

4. It's not clear to me, but it looks like notifications from the host
    are also unicast? MLDv2 routers are not required to accept unicast
    MLDv2 reports.

5. In 3.2 regarding responding to general queries, it says:
    "Only the active hosts that have bee receiving multicast contents
    should respond the Query message." Hosts are however required to
    send MLD reports for e.g. the solicited node multicast address.

6. Tuning of IGMPv3/MLDv2

    Based on our charter, we want a document on how to tune IGMPv3/MLDv2
    for mobile environments. Regarding this, the document mostly says
    that results will be provided in the future.

All in all, I think this document has some interesting ideas, but as it
is today, it doesn't fit our current charter milestones very well.

I'm hoping to get some discussion on these points and more reviews of
the document. What do you think Hitoshi-san?

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 29 Oct 2009 01:53:13 +0100

Hitoshi-san,

today I've read and thought about your draft, as well, and would like to 
share the following thoughts.

At first, it really has largely improved over version 00, so congrat to 
all your work.

Still I've a couple of comments /issues with it:

 From an overall perspective, it appears to me more like a collection of 
well informed, intelligent reflections on MLD and mutlicast-related 
issue than a stringent advisory on how to tune MLD. I could not capture 
a stringent design line that leads into a consistent mobility solution 
for optimized IGMP/MLD.

In particular, the draft proposes a couple changes to IGMP/MLD 
processing, operations and the semantic (see Stigs comments) so that it 
not only seems to escape from the charter, but the following impression 
came to my mind: If one changes the IGMP/MLD protocol to adapt to the 
mobile regime, then a few courageous changes would make the world much 
easier instead of a collection of "soft bendings". So for my taste, it 
appears much better to either not change IGMP/MLD at all (having the 
deployment priority), or change consequently and approach the 
optimization goal as closely as possible.

The document starts (introduction, 1st para) with a couple of clear 
problems and objectives extracted from [draft-irtf-mobopts-mmcastv6-ps], 
but later looses contact to the issues actually addressed.  So I got 
somehow lost in a collection of somewhat arbitrary propositions that are 
later justified by selected mobility problems.

Imho it would have been advantageous to clearly follow the problems and 
confront them with counter measures that resolve the issues.

Also, the issues and requirement on MN handover operations got somewhat 
lost in this document: In the mobility regime, IGMP/MLD are important to 
facilitate seamless listener handovers. Suppressing queries or delaying 
times may do significant harm here. Overall, there is an ambiguity on 
preserving resources on the one hand, and ensuring service on the other. 
It's not that simple!

After the general remarks, let me get into the details:

  *Scope*: Even though the charter emphasizes IGMPv3/MLDv2, I'm still 
not convinced why we should exclude the widespread previous standards ...
But in particular, I don't see any natural relation to MLD-light. 
MLD-light may be standardized elsewhere and addresses different 
(switching) issues. There is no need to tie mobility to MLD-light. It 
might even appear that the exclude mode is of particular interest to the 
mobility regime, where a receiver might want to reject a source that 
exhausts its resources. So I would suggest to cut out MLD light completely.

  *Explicit tracking*: This is a well known thing (already described in 
RFC 3810) and undoubtedly useful. However, it has to cope with the 
uncertainty about states after handovers. So it would be helpful to 
explore the design space in between the two driving forces, not just 
look at one.

Btw: I don't understand your 4th bullet point; "It is impossible to 
identify mobile hosts when hosts have the same
       IPv6 link-local address in some mobile routing environment such 
as PMIPv6"

  *Section 3.2* This essentially proposes protocol changes (switch to 
unicast) ...

  *Section 3.3* I don't see the issue, the discussion and the 
consequences (don't use explicit tracking) here ... I tend to suggest to 
cut it out.

  *Section 3.4* This section only advertises MLD-light, so IMHO it is 
obsolete.

  *section 4* This section changes MLD, so it is obsolete for now. 
However, it proposes an interesting transition from 
router/network-initiated reports to MN-initiated reports. Still, this 
does not appear mature to me. If an MN - unaware of its current handoff 
state - issues MLD reports at a frequency compliant to seamless 
handovers (say every 10 ms), then it annoys the network continuously. On 
the other hand, how do you want to detect ungraceful leaves? By erasing 
notes that have not reported for x*10 ms? Again I believe it is not that 
simple.

  *section 5* You identify some of the ambiguous issues, but do not 
provide counter measures. In particular, you identify compatibility 
problems with your approach.

  *section 6* Essentially empty.

In conclusion I believe much more thought and additional work is needed 
to address this problem effectively.

That are my thoughts for now.

Best regards,

thomas

Stig Venaas wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob