Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document

Hi, Imed:
Thank for your feedback, please see my reply inline.

Regards!
-Qin
----- Original Message ----- 
From: "Romdhani, Imed" <I.Romdhani@napier.ac.uk>
To: "Stig Venaas" <stig@venaas.com>; <multimob@ietf.org>
Sent: Wednesday, June 01, 2011 12:50 AM
Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document

> Dear all,
> 
> I am sorry for not commenting earlier on this draft. I would like to share with all folks some comments that I have already sent to the authors.
> 
> I endorse the proposal and I do support it. However, I have some comments on the draft. Overall, there is still a need to clarify and to distinguish between two aspects in the operation of IGMP/MLD. A clear distinction between Router Operation and Host Operation should be discussed especially when it comes to tuning decision either to speed up or to slow down control signalling messages.

[Qin]: I agree it is more valuable to discuss how IGMP/tuning works in mobility usage scenario rather than limited tuning mechanism to the pure wireless cases.

> Another point that the authors have probably "missed" to discuss is the case where a Mobility Agent (Home Agent, Proxy or Anchor Point) is a Querier. In this case, the agent has to run multiple instances of the IGMP/MLD processes on physical network interfaces and on tunnel interfaces. The behaviour of IGMP/MLD should be naturally different as the awareness level of the multicast membership is different.

[Qin]: You are talking about how to differentiate between remote subscription case and home subscription case? 
As I said, I agree to discuss how IGMP/MLD tuning is used in mobility scenario.
However I am not sure what's the difference of the behavior  of IGMP/MLD in two different cases mentioned above?

BTW: what kind of agent you are talking about process the IGMP/MLD message?
I suspect the agent is not mobility agent.

 In addition, the processes are not independent as one may affect the other. Fixed members may affect mobile devices that are away due to their join/leave activities.  

[Qin]: How, can you clarify it more?

> As the values of the different timers are concerned, I think there is no need to fix them. Authors have justified their choice based on analysis that they have done, but I think there should be a sort of variation (range that can be enlarged or shortened) depending on different circumstances and the layer 2 technology used.

[Qin]: Agree. It is reasonable to allow parameters to be tuned vary from different circumstances.

> Having a track record of mobile members may be easy to detect and maintain if the Home Agent is a Querier.

[Qin]: Agree since home agent or other agent can maintain the record of each mobile members in the mobility scenario.

 In other cases, I don't see who we can distinguish the origin of an IGMP/MLD report message (i.e. coming from a mobile or stationary device). Routers are connected in general to Wireless Domain Systems or Access Points and they are not directly connected to mobile devices (design assumption and management issue).

[Qin]: Why should we need to distinguish whther IGMP/MLD report message is sent from mobile device or a fixed device?

> Finally, a mobile device may need to speed up sending his IGMP/MLD report. As far as I know, in Mobile IP specification, a mobile device needs to wait first the reception of an IGMP/MLD query before being eligible to send a report (through the bidirectional tunnel), probably this is an implicit part of the Return Routability procedure (CoA needs to be validated before use).

[Qin]:As regarding to whether IGMP/MLD query is needed each time, I am afaid that I am not tending to agree. In some case, we need solicited 
 membership report, in some case, we use unsolicited membersip report. e.g., the first subscriber joins a multicast group, 
 or the last subscriber leaves a multicast group.

> Hope my comments help to improve the draft.
> 
> Kind Regards,
> Imed
> ---------------------------------------------------
> Imed Romdhani, PhD
> IEEE Member, FHEA 
> Lecturer in Networking
> Room C 64
> Edinburgh Napier University
> School of Computing
> 10 Colinton Road
> Edinburgh, EH10 5DT
> UK
> E-Mail:   I.Romdhani@napier.ac.uk
> Home Page: http://www.dcs.napier.ac.uk/~cs244/
> Telephone: +44(0)131 455 2726
> Fax: +44(0)131 455 2727
> ---------------------------------------------------
> 
> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Stig Venaas
> Sent: 26 May 2011 20:14
> To: multimob@ietf.org
> Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document
> 
> It looks like we have sufficient support to adopt this. Quite a few in
> favor and no one against.
> 
> Hitoshi, please resubmit as a wg document,
> 
> Stig
> 
> On 5/5/2011 12:50 PM, Stig Venaas wrote:
>> Hi
>>
>> The draft draft-asaeda-multimob-igmp-mld-optimization-05 was presented
>> in the wg meeting in Prague. We were asking about adoption there. A few
>> people supported it, none were against.
>>
>> To decide whether to adopt, we also need to check on the list.
>>
>> Please read the document, and state whether you think it is ready for
>> adoption or not.
>>
>> Note that we have in our charter to submit a document on how to tune
>> IGMPv3/MLDv2 for mobility.
>>
>> Stig
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>> https://www.ietf.org/mailman/listinfo/multimob
> 
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
> 
> 
> Edinburgh Napier University is Edinburgh's top university for graduate employability (HESA 2010), and proud winner of the Queen's Anniversary Prize for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life.
> 
> This message is intended for the addressee(s) only
> and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. 
> Edinburgh Napier University does not accept liability for any loss or
> damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. 
> 
> Edinburgh Napier University is a registered Scottish
> charity.
> Registration number SC018373
> 
> 
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob