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

Hi, Imed:
----- Original Message ----- 
From: "Romdhani, Imed" <I.Romdhani@napier.ac.uk>
To: "Qin Wu" <sunseawq@huawei.com>; "Stig Venaas" <stig@venaas.com>; <multimob@ietf.org>
Cc: "Romdhani, Imed" <I.Romdhani@napier.ac.uk>
Sent: Friday, June 03, 2011 4:49 PM
Subject: RE: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document

Dear Qin,
Dear Folks,

Thanks for these clarifications. To answer your question about the case when a mobility agent is an IGMP/MLD Querier, the latest Mobile IPv6 RFC for example (rfc3775bis-13, Section 10.4.3) highlights the necessity that the Home Agent implement a sort of "per-tunnel behaviour" for multicast membership control messages. This standard stated that "to avoid ambiguity on the home agent, due to mobile nodes which may choose identical link-local source addresses for their MLD function, it is necessary for the home agent to identify which mobile node was actually the issuer of a particular MLD message.  This may be accomplished by noting which tunnel such an MLD arrived by, which IPsec SA was used, or by other distinguishing means". The implication of that means that the tuning mechanism that we (Multimob) are proposing needs to be adapted or adjusted to each mobile node specific needs.  

[Qin]: Good point.

I am in favour of a windowing style management where the timers can be increased or decreased gradually and in an automated and intelligent way of possible. We can imitate the TCP windowing approach.

[Qin]:  Your proposal looks reasonable to me.

For the unsolicited report, you are right. Mobile nodes can send their Reports whenever they want independently of the subscription method (home or remote). In previous MIP standards, it was recommended that mobile nodes need to wait first the reception of IGMP/MLD query on the bi-directional tunnel before sending back their reports. For security raison, I think we cannot avoid the initial step of validating the CoA if the remote subscription is used.  What optimal subscription method a mobile node should use depends on many factors: availability of multicast service, access rights, scope boundaries, QoS performance, etc. If the home subscription is used, the Querier needs to speed up sending Query messages to mobile nodes to compensate the transfer delay. This may be also applicable in the remote subscription scenario, but any timer manipulations (in case where the HA is a Querier or IGMP/MLD forwarder for MNs) has be cautious! The behaviour of a mobile device may be different also in delaying his report messages depending on its awareness of which subscription method is used and the proximity of the IGMP/MLD Querier.

[Qin]:  Exactly. You have answered my question. Thanks.

Finally, it is worth clarifying the case where the Querier is not a router (case of IGMP/MLD Proxy for example). This will give us different IGMP/MLD tuning scenarios: simple router; router with mobility agent function: MIP access router, HA, Mobility Anchor Point; and IGMP/MLD proxy.

[Qin]: Agree. However the moblity protocol family is not limited to MIP, we also have PMIP, which one we should clarify first, which one we should focus on.

Again, I iterate my support for the adoption of this draft.

Kind regards,
Imed

-----Original Message-----
From: Qin Wu [mailto:sunseawq@huawei.com] 
Sent: 01 June 2011 05:29
To: Romdhani, Imed; Stig Venaas; multimob@ietf.org
Subject: 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

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