Subject: Re: [multimob] Revised MLD/IGMP Tuning drafts

From: Liuhui <[email-masked]>
Date: Tue, 02 Nov 2010 03:59:56 +0000

Hi Dirk,

Thanks for your detailed review and helpful suggestion :) 
Please see my considerations in-line: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, October 28, 2010 6:41 PM
> To: [email-masked]
> Subject: Re: [multimob] Revised MLD/IGMP Tuning drafts
> 
> Dear all,
> Please find below some suggestions to the Multimob MLD tuning drafts:
> 
> In general IMO both revised drafts have considerably 
> improved. Thanks to the autors for their effort!
>  
> Qin and Hui give a detailed introduction in wireless and 
> mobile multicast isues which could be shortened a bit (BTW 
> also fixed access bandwidth e.g. DSL in general is asymmetric 
> - however for wireless it could also be a hybrid connection 
> with e.g. broadcast e.g. DVB downlink and individual unicast 
> e.g. WLAN uplink). 

Accepted. We will shorten the introduction part, and emphasize wireless characteristics on asymmetric link as suggested.

> I am not sure whether we need a comparison in detail between 
> MLD/IGMP versions as only IGMPv3/MLDv2 is mentioned in the charter.

Yes, this section should be shortened to more general summarization.

> 
> Both drafts propose to use Explicit Tracking which can 
> considerably reduce message traffic and speed up leave 
> latency thus saving resources on both network and terminal 
> side. I don't understand why channel changing at receiver 
> side will speed up (3rd para on p.13, Wu et al.)- when a host 
> has sent the Leave it stops listening to the old channel and 
> can send Join to new group and start listening to them ...

Generally, explicit tracking is thought of beneficial for fast leave.  Because the router has exact knowledge of membership and when a receiver leaves, the router need not wait for the response of a Query to collect other member's state to decide the release of a channel.

In the case when bandwidth resources between router and receiver are limited (such as wireless application or wired xdsl applications), one channel is sometimes occupied by only one receiver.  Only if a channel is released, can it be used by another receiver.  The fast leave or releasing of one channel is the precondition of the joining by other receiver to enable it's changing to this channel. In this sense the changing channel is sped up by explicit tracking.

I think we could describe it more detailedly in next revision if needed.

> 
> Whereas Hitoshi and Yogo propose specific figures for Timers 
> and Counters (unfortunately without a reference to 
> measurements verifying the optimization gain), Qin and Hui 
> propose an adaptive Timer increase which seems to be more 
> elegant - but doesn't this require a protocol change?

Adaptive timer setting doesn't require protocol change IMHO.  Though it needs some interface between IGMP and other calculation module to set this parameter. The calculation itself is not in IGMP's scope, thus it will not change the protocol behavior.

> 'Switching between Unicast and Multicast Queries' is 
> implicitly also proposed by Hitoshi and Yogo ...

We propose this according  to the operating mode of MBMS in 3GPP, because multicast mode is not necessarily more efficient than unicast one in all scenarios (e.g when number of receiver is small)

> 
> Actually I don't see real controversary between both drafts 
> but rather to be complementary to each other - however I am 
> no expert on IGMP/MLD ... 
> My overall suggestion is that merging both documents could 
> provide a complete solution to be adopted by the WG.

We'd like to respect WG's decision on this issue. 

Best Regards,
Liu Hui

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 02 Nov 2010 18:41:46 +0900 (JST)

Hi Dirk,

> Qin and Hui give a detailed introduction in wireless and mobile
> multicast isues which could be shortened a bit (BTW also fixed
> access bandwidth e.g. DSL in general is asymmetric - however for
> wireless it could also be a hybrid connection with e.g. broadcast
> e.g. DVB downlink and individual unicast e.g. WLAN uplink). 

The draft aims to propose IGMP/MLD optimization by tuning timers or
other values.
Therefore, IMO, it is better that such detail description would be
included in other draft, e.g., the requirement draft, not in the
optimization draft, if needed.

> Both drafts propose to use Explicit Tracking which can considerably
> reduce message traffic and speed up leave latency thus saving
> resources on both network and terminal side.

The spec of the explicit tracking function has been proposed in the
following draft;
http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-01

> Whereas Hitoshi and Yogo propose specific figures for Timers and
> Counters (unfortunately without a reference to measurements
> verifying the optimization gain),

Right. Since I think describing the simulation scenarios may be out of
scope of the I-D, I've not included in the I-D.
I hope I could refer our paper in the revised draft.

> Qin and Hui propose an adaptive
> Timer increase which seems to be more elegant - but doesn't this
> require a protocol change?
> 'Switching between Unicast and Multicast Queries' is implicitly also
> proposed by Hitoshi and Yogo ...

Unicast general query is allowed in RFC3376 and 3810, and hence we had
proposed the use of unicast query for mobility since -00 version of
our optimization draft published on July 2009.
http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-optimization-00

However, I believe changing the destination address of general query
and changind the query interval "according to the network or node
condition" require protocol change. They are beyond the standard spec.

Since IMO it is a protocol change, the discussion about unicast vs.
multicast general query with different query intervals has been
discussed in the following "protocol extension" draft.
http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-mobility-extensions-04
It is not in the current charter, but if you are interested in, please
take a look at it.

> My overall suggestion is that merging both documents could provide a
> complete solution to be adopted by the WG.

At this moment I'm sorry but I cannot find any reason to merge the
draft.

Regards,
--
Hitoshi Asaeda