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

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Nov 2009 07:32:28 -0800 (PST)

I am forwarding Hitoshi's reply which somehow got stuck somewhere.

--behcet

>Stig,
> 
> > 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.
> 
> An important point we need to know is that there is no application
> using an EXCLUDE (S,G) operation. This draft aims to contribute to a
> guideline for mobile terminal and router implementations and
> configurations; hence describing the advantage of LW protocols is one
> of the task of this draft. This is my thought.
> 
> Additionally, it is obvious that an EXCLUDE mode operation does
> influence the routing infrastructure. Imagine that what happens if
> some of mobile nodes join EXCLUDE (S,G) when others join INCLUDE (S,G).
> Upstream mobile router just switches SPT to RPT for that EXCLUDE (S,G)
> request. The EXCLUDE join just breaks SSM communication.
> Of course, it'll be happened even with (*,G) join. However EXCLUDE
> (S,G) join does not create any benefit, and requires more complex
> states than (*,G) join state in routers.
> In summary, EXCLUDE (S,G) join gives the high possibility of unwilling
> routing condition. To eliminate the possibile worse scenario that an
> EXCLUDE operaion is misused or used by malicious users, I would highly
> recommend the use of LW-IGMPv3/MLDv2.
> 
> >    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.
> 
> While I don't deny to support the standard IGMPv3/MLDv2 in this draft,
> because of above thoughts, I propose to recommend to use
> LW-IGMPv3/MLDv2 for mobile communications.
> 
> > 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.
> 
> If it is the concensus of this WG, I move the statements to my
> extension draft for future.
> 
> > 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...
> 
> This draft does not deny multicasting general query at all. The
> advantage of unicasting general query is dependent on many factors,
> e.g. the number of active and non-active nodes attached on a wireless
> link, the amount of active traffic on a link, and so on. They are very
> dynamic in nature. What we need to understand in this draft is that we
> have possibile ideas to optimize the IGMP/MLD communication condition
> by several means. But if removing this section and moving this context
> to my extension draft are the concensus in this WG, I'll follow the
> decision.
> 
> (I confuse the meaning of this draft if I remove all of above.:)
> 
> > 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.
> 
> No, it should be multicast. I didn't mention the IP destination
> address for this operation, hence will do it in the next revision.
> Thanks.
> 
> > 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.
> 
> This section mentions "IGMP/MLD guery processing", so I thought this
> statements does not deny anything about ND or other multicast related
> communication.
> But if it's better to clearly mentioning;
> "Only the active hosts that have been receiving multicast contents
> should respond the IGMP/MLD Query messages"
> is better, I'll do it in the revised version.
> Does this make sense?
> 
> > 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.
> 
> If the charter requires to define only the definitive optimized timer
> values for each query to fit any kind of situation, it is too
> optimistic to fulfill such requirement.
> 
> Again, network condition and user condition are highly dynamic. And
> the network condition would be very different in various wireless
> link types. Showing the best definitive timer values are the real
> challenge.
> I prefer to at first describe the architectural scenarios of mobile
> multicast and then start discussion about relation between
> considerable conditions and each timer value if possible.
> 
> > I'm hoping to get some discussion on these points and more reviews of
> > the document. What do you think Hitoshi-san?
> 
> If someone will be able to show some or all of the best definitive
> timer values in common, I'm glad to cooperate with them for the
> revised draft.
> 
> Regards,
> --
> Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 05 Nov 2009 17:38:22 +0900 (JST)

Thomas,

> 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!

Frequent query with shorter timer SHOULD NOT be adopted for fast
handover. It does NOT give great benefit or rather gives heavy
wireless resource usage.
Just flooding query messages with shorter period is the real harm.
Instead, take new context transfer mechanism for fast handover, but it
is not the target of this draft.

>   *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.

Read my reply mail to Stig.

>   *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.

Don't send or flood frequent query messages, and study context
transfer for fast handover.

> 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"

Link-local address is not always ensured if DAD is omitted or failed.

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

It'd be configuration matter. Need opinion from router venders.

>   *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.

No reasonable explanation. Need more opinion from others.

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

Not true. Need more opinion from others.

>   *section 4* This section changes MLD, so it is obsolete for
> now.

What obsolete?
This section may be moved to my extension draft if concensus, though.

> 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.

If this section may be moved to my extension draft, the following
comments are not relevant, but I answer your question here.

You said "say every 10 ms", but this assumption is very bad. I guess
your assumption comes from the point of fast handover again, but it
should not.
I don't know what timer value is the best but it'd be a half of or
a little less than a half of the default general query timer (which is
10 sec.) in my current feeling.

For ungraceful leave, a router captures the MN's condition by regular
query. This draft does not eliminate general query.

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

Sorry, I cannot understand what you mean..

>   *section 6* Essentially empty.

Please read my mail replied to Stig.

Regards,
--
Hitoshi Asaeda