Subject: [multimob] IGMP/MLD optimizations

From: Olivier Dornon <[email-masked]>
Date: Mon, 6 Aug 2012 15:39:23 +0200

Hi,

Without being in favour of this being handled in the multimob or pim 
WG,  I just wanted to point out that igmp/mld routers might also benefit 
from these optimizations outside the scope of mobile networks.

Some of the issues you're addressing with this can also be encountered 
in highly scaled host networks, I'm thinking 10000+ hosts on a single 
link.  To give an example, in such cases a single query from the router 
will trigger 10 thousands of reports, the router could adapt his 
response delay according to the number of hosts, thus avoiding any queue 
overflows and message drops.

I was wondering whether you ever considered broadening the scope of this 
draft beyond mobility?

Olivier.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 08 Aug 2012 14:23:04 +0900 (JST)

Hi,

> link.  To give an example, in such cases a single query from the
> router will trigger 10 thousands of reports, the router could adapt
> his response delay according to the number of hosts, thus avoiding any
> queue overflows and message drops.
> 
> I was wondering whether you ever considered broadening the scope of
> this draft beyond mobility?

There are several ways to escape from the issue you raised up.

1. Disperse solicited report messages by tuning max resp code
   MLDv2 (rfc3810) query message specifies the max resp code, which
   allows the exponential values if you prefer to set it up longer
   than 32.768 sec. The longer you set it up, the more solicited
   report messages triggered by a single General query are dispersed.
   This tuning is very easy and can be done without any protocol
   modification, but the longer max resp code takes longer convergence
   for membership information and leads longer leave latency.
   This is written in rfc6636.

2. Reduce the number of unsolicited report messages by enabling the
   explicit tracking function
   The number of solicited report messages triggered by Specific query
   can be also reduced, if you turn on "the explicit tracking
   function" on leaf routers. This is because the router enabling that
   function can expect the existence of the last member whenever it
   receives a leave message and hence no need to confirm by sending
   Specific query.
   This function is not clearly defined in rfc3810, but recent
   routers may already support it.
   As the specification, it is written in the following I-D;
   http://tools.ietf.org/id/draft-ietf-pim-explicit-tracking-01.txt

3. Control solicited report message transmission by unicasting General
   query
   When a multicast router enables the above explicit tracking
   function, it is possible for the router to track the membership
   status for each member host by unicasting General query. This
   contributes to reduction of flooding General query messages on a
   link, and hence reduces the network resource and the CPU usage of
   hosts.
   However, as written in Appendix A of rfc6636, this would require
   IGMP/MLD protocol extension.

Hope this helps.

Regards,
--
Hitoshi Asaeda