Subject: Re: [multimob] Fw: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt

From: Qin Wu <[email-masked]>
Date: Tue, 20 Jul 2010 16:22:02 +0800

Hi, Weesan:
Thank for your valuable comments and detailed input. please see my feedback belows.

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: "Qin Wu" <[email-masked]>
Sent: Friday, July 16, 2010 8:08 AM
Subject: Re: Fw: [multimob] Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt

> Hi Qin,
> 
> Sorry for the long delay.  Please find below my comments/questions
> regarding your draft in the diff format.  Feel free to address those
> privately or repost it to the mailing list.

> You may need to mention in this document that you are focusing
> only on the last hop router where the mobile nodes will be
> communicating to.  In the document, you mentioned wired multicast and
> wireless multicast, in fact, this document focuses only on IGMP/MLD,
> which is one part of the multicast protocol suites.

[Qin]: You are right. but multicast routing protocol is 
out scope of this document. Any changes to the multicast 
routing protocol should be beyond scope of multimob 
WG, if my understanding is correct.

> -- 
> Thanks,
> -WeeSan
> 
> --------- begin diff ------------
> *** draft-wu-multimob-igmp-mld-tuning-02.txt.orig 2010-06-20 17:21:38.000000000 -0700
> --- draft-wu-multimob-igmp-mld-tuning-02.txt 2010-07-15 16:55:43.000000000 -0700
> ***************
> *** 123,154 ****
>  
>  1. Introduction
>  
> !    Multicasting is more efficient a method of supporting group
>     communication than unicasting. However, it has seen slow commercial
>     deployment by ISPs and carriers for limited number of applications
> !    and the complexity of the architecture design [DEPLOY]. Along With
> !    the wide deployment of different wireless networks, multicast
> !    communication over wireless network comes to attract more and more
> !    interests from content and service providers, but still faces great
> !    challenges when considering it to keep up with node movement and
> !    frequent topology change and providing efficient service in the new
> !    wireless environment, e.g., dynamic group membership and constant
>     update of delivery path due to node movement is highly required in
>     the wireless network.
>  
> !    On the other hand, unlike shared-medium wired LAN, some of wireless
> !    networks, e.g. Wireless 802.11 WLAN offer limited reliability and
> !    consume more power and cost more transmission overhead, in the worse
>     case, it is more prone to cause congestion.
>  
> !    Considering the existing multicast communications is designed only
> !    for fixed users using wired link, it does not work well for all the
> !    wireless link types.  Therefore IGMP/MLD protocol should be enhanced
>     or tuned to adapt to wireless environment to meet the reliability
>     and efficiency requirements in the scenarios described in [REQUIRE].
>  
> !    This memo proposes a variety of optimization approaches for tuning
> !    IGMP/MLD protocols in wireless or mobile communication environment.
>     It aims to make the minimum tuning without introducing obvious
>     changes on the protocol behavior.  These solutions can also be used
>     in wired network when efficiency and reliability are required.  They
> --- 123,159 ----
>  
>  1. Introduction
>  
> !    Multicasting is a more efficient method of supporting group
>     communication than unicasting. However, it has seen slow commercial
>     deployment by ISPs and carriers for limited number of applications
> !    and the complexity of the architecture design [DEPLOY].  This is
> !    going to change with
> !    the wide deployment of different wireless networks.  Although multicast
> !    communication over the wireless networks has become more attractive
> !    to the content and service providers, it is still facing great
> !    challenges such as rapid and frequent topology changes, as well as
> !    striving for providing efficient service in the new
> !    wireless environment.  For example, dynamic group membership and constant
>     update of delivery path due to node movement is highly required in
>     the wireless network.
>  
> !    Additionally, unlike shared-medium wired LAN, some of wireless
> !    networks, e.g. Wireless 802.11 WLAN offers limited reliability,
> !    consumes more power and costs more transmission overhead.  In the worse
>     case, it is more prone to cause congestion.
>  
> !    Given the fact that the existing multicast protocols were designed only
> !    for using wired networks, they do not work well for 
> !    wireless environment.  Therefore IGMP/MLD protocol should be enhanced
>     or tuned to adapt to wireless environment to meet the reliability
>     and efficiency requirements in the scenarios described in [REQUIRE].
>  
> ! weesan: You should mention this document focuses only the last mile of
> ! the multcast forwarding path.

[Qin]: Thanks, but we mostly focus on multicast management protocol like IGMP/MLD instead of 
multicast routing protocol like PIM/SIM.

> !    This memo proposes various optimization approaches for tuning
> !    IGMP/MLD protocols that will fit in wireless or mobile
> !    communication environment.
>     It aims to make the minimum tuning without introducing obvious
>     changes on the protocol behavior.  These solutions can also be used
>     in wired network when efficiency and reliability are required.  They
> ***************
> *** 177,201 ****
>     IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication
>     mode. They do not support SSM subscription, which may limit their
>     widespread deployment in practical multicast network. IGMPv3
>     [RFC3376] and MLDv2 [RFC3810] and their lightweight version LW-
>     IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM and SSM
> !    communication. Comparing with ASM mode, SSM [RFC4607] mode allows
> !    only sources specific multicast delivery and reduce the demand on
> !    the network and improve security by so limiting the source.
>     Therefore SSM mode is much better to be candidates for wireless and
> !    mobile networks than their previous versions.
>  
>     IGMPv3/MLDv2 Explicit join and leave Reports are the messages sent
> !    unsolicitedly when a host intends to join or leave a group.  They
>     are beneficial for ensuring satisfactory user experience and must be
>     guaranteed to improve service performance and to optimize resource
>     use. Current IGMPv3 and MLDv2 provide the reliability for these
> !    messages by non responsive retransmission, which is not guaranteed
>     the messages to be retransmitted is received and may be not adequate
>     from both the robustness and efficiency aspects [ROBUST]. This issue
>     could be enhanced by acknowledgement-retransmission in [ACK][IGMP-
>     ACK].
>  
>     In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to
>     suppress duplicated multicast listener reports on the link. In
>     IGMPv3 and MLDv2, there is no such host suppression and explicit
> --- 182,225 ----
>     IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication
>     mode. They do not support SSM subscription, which may limit their
>     widespread deployment in practical multicast network. IGMPv3
> + 
> + weesan: I'm not sure if this is true.  When PIM switches to SPT, it
> +         essentially is in SSM mode.  IGMPv3 simply provides a way to
> +         jump to SSM mode without going through the RP.

[Qin]: What I am saying here is: in contrast with ASM, SSM has  more widely deployment.
Is that true?

>     [RFC3376] and MLDv2 [RFC3810] and their lightweight version LW-
>     IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM and SSM
> !    communication. Unlike ASM mode, SSM [RFC4607] mode allows
> !    only sources specific multicast delivery and reduces the demand on
> !    the network and improve security by limiting the source.
> ! 
> ! weesan: how does to SSM reduce the demand on the network?  Did you
> !         mean it eliminates the needs of creating (*,g) routes and thus
> !         reduces the overhead of maintaining them?

[Qin]: Yes, By limiting the source, SSM reduces demands on the network.

> ! 
>     Therefore SSM mode is much better to be candidates for wireless and
> !    mobile networks than ASM mode.
>  
>     IGMPv3/MLDv2 Explicit join and leave Reports are the messages sent
> !    unsolicitedly when a host intends to join and leave a group
> !    respectively.  They
>     are beneficial for ensuring satisfactory user experience and must be
>     guaranteed to improve service performance and to optimize resource
>     use. Current IGMPv3 and MLDv2 provide the reliability for these
> !    messages by non-responsive retransmission, which is not guaranteed
>     the messages to be retransmitted is received and may be not adequate
>     from both the robustness and efficiency aspects [ROBUST]. This issue
>     could be enhanced by acknowledgement-retransmission in [ACK][IGMP-
>     ACK].
> ! 
> ! weesan: I think I understand what you're saying, but, what is a
> !         "non-responsive retransmission"?  

[Qin]: No-responsive retransmission means the host join or leave group by 
sending unsolicited report and can not get response from the router.

>!             I don't think neither IGMPv3
> !         nor MLDv2 provide any reliability.  They are soft-state
> !         protocols.  They increase the robustness by retransmission.

[Qin]: Isn't that what I am saying in the document? 

>  
> + weesan: The ack would provide reliability.

[Qin]: Yes.

> + 
>     In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to
>     suppress duplicated multicast listener reports on the link. In
>     IGMPv3 and MLDv2, there is no such host suppression and explicit
> ***************
> *** 210,215 ****
> --- 234,247 ----
>     leave messages and simplify the Query mechanism by reducing both the
>     unnecessary Queries and reports generated on a network.
>  
> + weesan: From the tone from the 2 paragraphs above, I'm not sure if
> +         host suppression and explicit tracking are good things or not.
> +         It sounded like you were trying to convince the readers that
> +         explicit tracking is a good thing, and we can use that to
> +         reduce unnecessary queries and reports.  Am I correct?  If so,
> +         what if explicit tracking is enabled on a router, and a mobile
> +         host joins a group and then is turned off, what would happen
> +         then?
  
[Qin]: 
Explicit tracking is a good feature when IGMP/MLD works in the wireless environment while host supression is not.
We can benefit a lot from using Explicit tracking, e.g.,
1. minimizing packet number and packet burst
2. Minimal leave latencies
3.Faster channel changing
4.Reducing Power consumption
Also explicit tracking can be used with report suppression and query supression mechanism to minimize the packet number.

 Suppose one mobile host joins a group and left, what the explicit tracking on the router is doing is to
remove the membership state for this mobile host from the table, which reduces unecessary query from 
upstream router and the report from the host.
 
> ***************
> *** 232,240 ****
>     to adapt to wireless and mobile scenarios. Also some enhanced
>     mechanism with no protocol changes can be employed as well.
>     Considering an enhancement in one direction might introduce side
> !    effects in another one, balances should be taken carefully to avoid
> !    defects and improve protocol performance as a whole, the comparison
> !    between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated in figure 2.
>  
>     +---------------------+----------------------+-------------------+
>     |      Issues         |     IGMPv2/MLDv1     |     IGMPv3/MLDv2  |
> --- 264,272 ----
>     to adapt to wireless and mobile scenarios. Also some enhanced
>     mechanism with no protocol changes can be employed as well.
>     Considering an enhancement in one direction might introduce side
> !    effects in another one, balance should be taken carefully to avoid
> !    defects and improve protocol performance as a whole.  The comparison
> !    between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated in Figure 2.
>  
>     +---------------------+----------------------+-------------------+
>     |      Issues         |     IGMPv2/MLDv1     |     IGMPv3/MLDv2  |
> ***************
> *** 244,250 ****
>     |                     |   Need to be tuned   |   Need to be tuned|
>     +---------------------+----------------------+-------------------+
>     |                     |                      |                   |
> !    | Explicit Tracking   |     Not Support      |        Support    |
>     |                     |                      |                   |
>     +---------------------+----------------------+-------------------+
>     |   ASM and SSM       |   Only Support ASM   |                   |
> --- 276,282 ----
>     |                     |   Need to be tuned   |   Need to be tuned|
>     +---------------------+----------------------+-------------------+
>     |                     |                      |                   |
> !    | Explicit Tracking   |     Not Supported    |        Supported  |
>     |                     |                      |                   |
>     +---------------------+----------------------+-------------------+
>     |   ASM and SSM       |   Only Support ASM   |                   |
> ***************
> *** 260,266 ****
>     +---------------------+----------------------+-------------------+
>          Figure 1. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2
>  
> ! 
> --- 292,299 ----
>     +---------------------+----------------------+-------------------+
>          Figure 1. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2
>  
> ! weesan: Figure 1 should be mentioned in the text somewhere but it's
> !         not.

[Qin]: Okay. The change will be reflected in the new version.
 
> ***************
> *** 275,313 ****
>  3. Impact of wireless and mobility on IGMP/MLD
>  
>     This section first evaluates the impact of wireless on mobility on
> !    IGMP/MLD by comparing wireless multicast with wired multicast and
>     comparing different wireless link models. And then gives the
>     characteristics requirement of wireless multicast.
>  
>  3.1. Comparison analysis between wired and wireless multicast
>  
> !    Existing multicast support for fixed user can be extended to mobile
>     users in wireless environments. However applying such support to
> !    wireless multicast is difficult for the following five reasons.
>  
> !    O Limited Bandwidth: In contrast with wired multicast, wireless
>        multicast usually has limited bandwidth. Also the bandwidth
>        available in upstream direction and downstream direction may not
>        be equal.
>  
> !    O Large packets Loss: In contrast with wired multicast, wireless
>        multicast has large packet loss that range between 1%~30% based on
>        the links.
>  
> !    O Frequent Membership change: In the wired multicast, membership
>        change only happens when a user leave or joins a group while in
>        the wireless multicast, membership changes may also occur when a
> !       user changes the location.
>  
> !    O Reliability: Due to possible unwanted interaction of protocols
>        across layers and user movement, the wireless network may be
>        overwhelmed with more excessive traffic than wired network. In
>        worse case, this may lead to network performance degrading and
> !       network connection complete loss.
>  
> !    O Increased Leave Latency: Unlike wired multicast, the leave latency
>     in the wireless multicast will be increased with user movement.
>  
> --- 308,353 ----
>  3. Impact of wireless and mobility on IGMP/MLD
>  
>     This section first evaluates the impact of wireless on mobility on
> !    IGMP/MLD by comparing wired and wireless multicast, and
>     comparing different wireless link models. And then gives the
>     characteristics requirement of wireless multicast.
>  
>  3.1. Comparison analysis between wired and wireless multicast
>  
> !    Existing multicast support for fixed users can be extended to mobile
> ! 
> ! weesan: what are "fixed" users?  Did you mean users of wired network?

[Qin]: Yes, any ambiguity introduced?
 
>     users in wireless environments. However applying such support to
> !    wireless multicast is difficult for the following five reasons:
>  
> !    o Limited Bandwidth: In contrast with wired multicast, wireless
>        multicast usually has limited bandwidth. Also the bandwidth
>        available in upstream direction and downstream direction may not
>        be equal.
>  
> !    o Large packets Loss: In contrast with wired multicast, wireless
>        multicast has large packet loss that range between 1%~30% based on
>        the links.
>  
> !    o Frequent Membership change: In the wired multicast, membership
>        change only happens when a user leave or joins a group while in
>        the wireless multicast, membership changes may also occur when a
> !       user changes the location (ie. move from one cell tower to
> !       another).
>  
> !    o Reliability: Due to possible unwanted interaction of protocols
>        across layers and user movement, the wireless network may be
>        overwhelmed with more excessive traffic than wired network. In
>        worse case, this may lead to network performance degrading and
> !       a complete network connection loss.
>  
> !    o Increased Leave Latency: Unlike wired multicast, the leave latency
>     in the wireless multicast will be increased with user movement.
>  
> + weesan: why is it related to user mobility?  I thought the increase
> +         was due to more packet losses (and thus missing leave reports)
> +         in wireless environment.
>  
>  
>  
> ***************
> *** 361,366 ****
> --- 401,409 ----
>            Figure 2. Comparison between wired multicast
>                      and wireless multicast
>  
> + weesan: why does the wired multicast have "frequent" packet losses?
> +         Did you mean "infrequent"?
> + 
>  3.2. Link models analysis for wireless multicast
>  
>    There are various type of wireless links. Each link type has
> ***************
> *** 369,376 ****
>    by unicast retransmission. In this document, we categorize the
>    wireless link type into three typical link models:
>  
> !   O PTP link model
> !   O PTMP link model
>  
> --- 412,419 ----
>    by unicast retransmission. In this document, we categorize the
>    wireless link type into three typical link models:
>  
> !   o PTP link model
> !   o PTMP link model
>  
>  
>  
> ***************
> *** 379,396 ****
>  Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior        June 2010
>  
>  
> !   O Broadcast link model
>  
>    Point to Point link model is the model with one dedicated link that
>    connects exactly two communication facilities. In this model, each
> !   link has only one receiver and the bandwidth is dedicated for each
>    receiver. Also one unique prefix or set of unique prefixes will be
>    assigned to each receiver. Such link model can be accomplished by
>    running PPP on the link or having separate VLAN for each receiver.
>  
>    PTMP link model is the model with multipoint link which consist of a
>    series of receivers and one centralized transmitter. Unlike P2P link
> !   model, Bandwidth and prefix in this model are shared by all the
>    receivers on the same link. Therefore Duplicate Address Detection (DAD)
>    should be performed to check whether the assigned address is used by
>    other receivers.
> --- 422,439 ----
>  Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior        June 2010
>  
>  
> !   o Broadcast link model
>  
>    Point to Point link model is the model with one dedicated link that
>    connects exactly two communication facilities. In this model, each
> !   link has only one receiver and the bandwidth is dedicated for the
>    receiver. Also one unique prefix or set of unique prefixes will be
>    assigned to each receiver. Such link model can be accomplished by
>    running PPP on the link or having separate VLAN for each receiver.
>  
>    PTMP link model is the model with multipoint link which consist of a
>    series of receivers and one centralized transmitter. Unlike P2P link
> !   model, bandwidth and prefix in this model are shared by all the
>    receivers on the same link. Therefore Duplicate Address Detection (DAD)
>    should be performed to check whether the assigned address is used by
>    other receivers.
> ***************
> *** 514,520 ****
>     these characteristics requirement into account, we will discuss
>     several optimization approaches for tuning of IGMP and MLD in the
>     wireless environment.  The optimizations try to minimize the packet
> !    transmission for both the Reports and Queries, and at the meanwhile
>     take the factor of improving reliability into account, with minimum
>     cost.  The different link types are also considered when varying
>     behavior and parameters.
> --- 557,563 ----
>     these characteristics requirement into account, we will discuss
>     several optimization approaches for tuning of IGMP and MLD in the
>     wireless environment.  The optimizations try to minimize the packet
> !    transmission for both the Reports and Queries, and at the sametime
>     take the factor of improving reliability into account, with minimum
>     cost.  The different link types are also considered when varying
>     behavior and parameters.
> ***************
> *** 526,533 ****
>     sent when a receiver leaves a (*,G) group, and Source-and-Group
>     Specific Query sent when a receiver leaves  an (S,G) group.  These
>     Queries have different functional scope.  They are used to fetch and
> !    refresh the downstream membership information by being responded by
> !    solicited reports.
>  
>     This section lists the possible optimization approaches for Query
>     messages.  The solutions are not intended to be adopted altogether
> --- 569,576 ----
>     sent when a receiver leaves a (*,G) group, and Source-and-Group
>     Specific Query sent when a receiver leaves  an (S,G) group.  These
>     Queries have different functional scope.  They are used to fetch and
> !    refresh the downstream membership information by responding to
> !    unsolicited reports.
>  
>     This section lists the possible optimization approaches for Query
>     messages.  The solutions are not intended to be adopted altogether
> ***************
> *** 545,555 ****
>  
>     In the IGMPv2/MLDv1, the multicast listener reports are suppressed
>     if the same report has already been sent by another host in the
> !    network which is also referred to as host suppression. As described
>     in the A.2 of [RFC3810], the suppression of multicast listener
>     reports has been removed in MLDv2 due to the following reasons:
>  
> !    O Routers may want to track per-host multicast listener status on an
>        interface. This enables the router to track each individual host
>        that is joined to a particular group or channel and allow minimal
>        leave latencies when a host leaves a multicast group or channel.
> --- 588,598 ----
>  
>     In the IGMPv2/MLDv1, the multicast listener reports are suppressed
>     if the same report has already been sent by another host in the
> !    network which is also known as host suppression. As described
>     in the A.2 of [RFC3810], the suppression of multicast listener
>     reports has been removed in MLDv2 due to the following reasons:
>  
> !    o Routers may want to track per-host multicast listener status on an
>        interface. This enables the router to track each individual host
>        that is joined to a particular group or channel and allow minimal
>        leave latencies when a host leaves a multicast group or channel.
> ***************
> *** 568,591 ****
>        In comparison, the previous version of MLD required that each
>        multicast address be reported in a separate message.
>  
> !    In these reasons, one important reason is for per-host tracking at
> !    the router which is also referred to as explicit tracking. Explicit
>     tracking is used to explicitly keep track the membership of all
>     multicast hosts in the access network which simplifies the Query
> !    mechanism by reducing both the unnecessary Queries and reports
>     generated on a network.
>  
>     When explicit tracking is enabled on a router, the local replication
>     can be used by the router to inspect incoming join and leave
>     requests, record or refresh the membership state for each host on
>     the interface, and take appropriate action to each received report.
> !    In the meanwhile, the router builds a table to track which channel
> !    being forwarded to each port. If the channel being requested to view
> !    is already being received at the router, it can replicate the stream
> !    and forward to this new requester which ensure good response time,
> !    but we should note that the router must ensure enough bandwidth
>     available to service the request.
>  
> --- 611,637 ----
>        In comparison, the previous version of MLD required that each
>        multicast address be reported in a separate message.
>  
> !    Among these reasons, one important reason is for per-host tracking at
> !    the router which is also known as explicit tracking. Explicit
>     tracking is used to explicitly keep track the membership of all
>     multicast hosts in the access network which simplifies the Query
> !    mechanism by reducing both the unnecessary Queries and Reports
>     generated on a network.
>  
>     When explicit tracking is enabled on a router, the local replication
>     can be used by the router to inspect incoming join and leave
>     requests, record or refresh the membership state for each host on
>     the interface, and take appropriate action to each received report.
> !    Meanwhile, the router builds a table to track which channel is
> !    being forwarded to which port. If the requested channel 
> !    has already been received on the router, the router can replicate
> !    and forward the stream 
> !    to this new requester.  This will ensures good response time.
> !    We should note that the router must ensure enough bandwidth
>     available to service the request.
>  
> + weesan: I don't quite get this.  My understanding of explicit tracking
> +         is used for leave requests rather than joins.

[Qin]: Not exactly, when one new host joins, the membeship state for this new
host need to be added into table maintained by the router. This table will be used
to keep track of hosts.
 
>  
>  
> ***************
> *** 609,615 ****
>     explicit tracking is used. But this does not mean that explicit
>     tracking can not be used with General periodical Query and current
>     state report in response to General Query. In some cases (e.g.,
> !    explicit join and leave message from hosts are lost), the Explicit
>     tracking may depend on current state report to refresh the
>     membership state by sending General Query. But different from using
>     Group specific Query, General Query is periodical message sent by a
> --- 655,661 ----
>     explicit tracking is used. But this does not mean that explicit
>     tracking can not be used with General periodical Query and current
>     state report in response to General Query. In some cases (e.g.,
> !    explicit join and leave messages from hosts are lost), the Explicit
>     tracking may depend on current state report to refresh the
>     membership state by sending General Query. But different from using
>     Group specific Query, General Query is periodical message sent by a
> ***************
> *** 618,643 ****
>     explicit tracking may update membership state periodically by using
>     periodical IGMP/MLD Query.
>  
>     The main benefits of using explicit tracking without Group specific
>     Query or Source-and-Group Specific Queries are that it provides:
>  
> !    O minimizing packet number and packet burst: Elimination of Group and
> !    Source-Group specific Queries in case a member leaves a group will
> !    reduce the great number of transmitted Group Specific Queries. And
>     finally the total number of Reports in response to Group Specific
>     Queries can be drastically reduced.
>  
> !    O Minimal leave latencies: That is to say, a router configured with
>     IGMPv3/MLDv2 and explicit tracking can immediately stop forwarding
>     traffic if the last host to request to receive traffic from the
>     router indicates that it no longer wants to receive traffic.
>  
> !    O Faster channel changing: The channel change time of the receiver
>     application depends on the leave latency, that is to say, single host
>     can not receive the new multicast stream before forwarding of the old
>     stream has stopped.
>  
> !    O Reducing Power consumption: Due to elimination of the suppression
>     of multicast listener reports, the host does not need to spend
>     processing power to hear and determine if the same report has already
>     been sent by another host in the network and therefore suppress the
> --- 664,695 ----
>     explicit tracking may update membership state periodically by using
>     periodical IGMP/MLD Query.
>  
> + weesan: you should consider breaking long sentences into smaller ones
> +         in the paragraph above.

[Qin]: Okay.

> + 
>     The main benefits of using explicit tracking without Group specific
>     Query or Source-and-Group Specific Queries are that it provides:
>  
> !    o minimizing packet number and packet burst: Elimination of Group and
> !    Source-Group specific Queries in case a member leaves a group.  This will
> !    reduce the number of transmitted Group Specific Queries. And
>     finally the total number of Reports in response to Group Specific
>     Queries can be drastically reduced.
>  
> !    o Minimal leave latencies: That is to say, a router configured with
>     IGMPv3/MLDv2 and explicit tracking can immediately stop forwarding
>     traffic if the last host to request to receive traffic from the
>     router indicates that it no longer wants to receive traffic.
>  
> !    o Faster channel changing: The channel change time of the receiver
>     application depends on the leave latency, that is to say, single host
>     can not receive the new multicast stream before forwarding of the old
>     stream has stopped.
>  
> ! weesan: not necessary true.  The old stream might keep coming while
> !         the new stream starts.

[Qin]: Okay, But My assumption is each host has one interface used to receive the data packets.
Also it is hard to forward the old stream to the mobile host without awareness of current location of mobile host.

> ! 
> !    o Reducing Power consumption: Due to elimination of the suppression
>     of multicast listener reports, the host does not need to spend
>     processing power to hear and determine if the same report has already
>     been sent by another host in the network and therefore suppress the
> ***************
> *** 656,666 ****
>     can be mitigated by aggregating the multicast group records in one
>     single report message.
>  
>     On the other hand, when explicit tracking is enabled at the router,
>     the router may consume more memory and processing overhead to store
>     the membership state of all hosts on the interface, especially when
>     explicit tracking is used with General Query. This issue can be
> !    optimized by separation of processing state changing report and
>     current state report. That means the router with explicit tracking
>     support will not send General Query to refresh membership state at
>     this router and only take action to the state change report, e.g.,
> --- 708,722 ----
>     can be mitigated by aggregating the multicast group records in one
>     single report message.
>  
> + weesan: it depends.  Usually, the control messages such as membership
> +         reports are far less than the data itself.  I'm not sure how
> +         much you can save power here.

[Qin]: yes, it depends on the deployment scale.

>  4.1.2. Report Suppression for the hosts
>  
> !    A large number of Reports on the bad links may result in
> !    packets burst. This problem can be mitigated by having the
>     router aggregate the responses (membership reports) from multiple
>     clients. The router can intercept IGMP/MLD reports coming from hosts,
>     and forwards a summarized version to the router only when necessary.
>     Typically this means that the router will forward IGMP/MLD membership
>     reports as follows:
>  
> + weesan: I didn't follow.  Report suppression is supposed to work on
> + the hosts, not the routers.

[Qin]: Report Suppression is done in the intermediate router between the host and upstream router.
The intermediate router can be DSLAM.

>  The large number of Queries and bad link condition may result in
>  packets burst. This packet burst can be mitigated by having the
>  downstream router stop forwarding IGMP/MLD Queries packets sent to
> the hosts and respond with report as proxy to the upstream router.
>  Typically this means that the router will:
>  
> + weesan: I'm confused.  The upstream router doesn't have to know the
> + group membership.  It's the last hop router's responsibility.

[Qin]: The upstream router can be last hop router. The downstream router can be DSLAM.
So I don't think any issue here.

>  
> ***************
> *** 716,721 ****
> --- 781,789 ----
>     address listener information from an attached link. This General
>     Query can be slowed down when a router can not collect successfully
>     all the members' report responses in the meanwhile the network
> + 
> + weesan: how do you know "all" the members?  Is it by explicit tracking?

[Qin]: Yes, one possible way is through explicit tracking.

>     congestion is going to happen [ADAPTIVE]. Its basic behavior is: the
>     router after sending a Query, if acquires the response from the
>     receiver, refreshes its state database and stop the querying
> ***************
> *** 727,732 ****
> --- 795,805 ----
>     receiver is unreachable and then stops the sending of the Query
>     ultimately.
>  
> + weesan: let's say if a wireless node is experiencing congestion
> +         because the lost of leave message to the router and the node
> +         is bombarded with unwanted data packets.  Backing up the
> +         General Queries would only make it worst, right?

[Qin]: You can not abandon or eliminate General Queries. In many cases, 
the General Queries has its value used to refresh the membership state. What 
we are doing to General Queries is just to slow down the interval for Query
retransmission. Nothing Else.

>     This query retransmission with incremental interval enables the
>     router to reduce the total packet retransmission times in the same
>     time period comparing with retransmission for multiple times with
> ***************
> *** 771,778 ****
>     Group-and-Source specific Query, can be retransmitted several times
>     within a given time interval. And also described in [RFC3376] and
>     [RFC3810], General Query can be retransmitted [Startup Query Count]
> !    with [Startup Query Interval].In some case, a router which keeps
> !    track of all its active receivers, if after sending a Query, may fail
>     to get any response from any receiver. And it may derive that this
>     Query might have been lost before reaching the other end of the link.
>     In such case, the router could choose to compensate this situation by
> --- 844,851 ----
>     Group-and-Source specific Query, can be retransmitted several times
>     within a given time interval. And also described in [RFC3376] and
>     [RFC3810], General Query can be retransmitted [Startup Query Count]
> !    with [Startup Query Interval].In some cases, a router which keeps
> !    track of all its active receivers, after sending a Query, may fail
>     to get any response from any receiver. And it may derive that this
>     Query might have been lost before reaching the other end of the link.
>     In such case, the router could choose to compensate this situation by
> ***************
> *** 781,789 ****
>     retransmission timer expires and the response from receiver has not
>     arrived, then another Query will be retransmitted.
>  
>  4.1.7. Filtering unwanted multicast packets based on link type
>  
> !     When the network needs to deliver packets to the receiver, the
>      receiver may be in the dormant mode. In such case, Paging capability
>      will be used to establish connection with the network when the
>      receiver is waken up. Before the connection is established, packets
> --- 854,865 ----
>     retransmission timer expires and the response from receiver has not
>     arrived, then another Query will be retransmitted.
>  
> + weesan: how do you differentiate if a General Query with no responses
> +         is the result of congestion or no receiver at all?

[Qin]: Explicit tracking can be used to  learn whether there still one receiver on the attached link. 
As for congestion, extra mechanism is required,e g, link state indication to the router.

>  4.1.7. Filtering unwanted multicast packets based on link type
>  
> !     When a router needs to deliver packets to a mobile receiver, the
>      receiver may be in the dormant mode. In such case, Paging capability
>      will be used to establish connection with the network when the
>      receiver is waken up. Before the connection is established, packets
> ***************
> *** 811,817 ****
>  
>      reduce possibility of MLD traffic burstiness. However, a longer
>      Maximum Response Delay in Multicast Address Specific and Multicast
> !     Address and Source Specific Queries extends the leave latency (the
>      time between when the last listener stops listening to a source or
>      multicast address and when the traffic stops flowing.) In order to
>      avoid burstiness of MLD traffic and reduce leave latency, we can
> --- 887,893 ----
>  
>      reduce possibility of MLD traffic burstiness. However, a longer
>      Maximum Response Delay in Multicast Address Specific and Multicast
> !     Address and Source Specific Queries increases the leave latency (the
>      time between when the last listener stops listening to a source or
>      multicast address and when the traffic stops flowing.) In order to
>      avoid burstiness of MLD traffic and reduce leave latency, we can
> ***************
> *** 822,829 ****
>      the expected number of Reporters for each Query and link type and
>      link status.
>  
> !     O If the expected number of Reporters is large and link condition is
>      bad, the system administrator MUST choose the longer Maximum
>      Response Delay; If the expected number of Reporters is small and the
>      link condition is good, the administrator may choose the smaller
>      Maximum response Delay. In this case, the MLD traffic burstieness
> --- 898,911 ----
>      the expected number of Reporters for each Query and link type and
>      link status.
>  
> !     o If the expected number of Reporters is large and link condition is
>      bad, the system administrator MUST choose the longer Maximum
> + 
> + weesan: by "choose", did you mean a preset value?  The thing is
> +         multicast is very dynamic, a choosen value for this hour might
> +         not good for the next hour.  Do you have a way to dynamically
> +         derive a "good enough" value?

[Qin]: Good question. I believe more testing results are required to derive
good enough value. Currently we don't have.

>      Response Delay; If the expected number of Reporters is small and the
>      link condition is good, the administrator may choose the smaller
>      Maximum response Delay. In this case, the MLD traffic burstieness
> ***************
> *** 841,849 ****
>      destination addresses are multicast addresses and also allow use of
>      unicast Queries with unicast destination.  The unicast Query is sent
>      only for one destination and has the advantages of not affecting
> !     other host on the same link.  But in some cases(e.g., during the
>      Queries on startup)using unicast Query instead of multicast
> !     Query ,the number the valid multicast receiver on the same link may
>      be large, i.e., numerous Queries will be generated for each member,
>      which will not be an efficient use of link resources.  In this case
>      the normal multicast Query will be a good choice because only one
> --- 923,931 ----
>      destination addresses are multicast addresses and also allow use of
>      unicast Queries with unicast destination.  The unicast Query is sent
>      only for one destination and has the advantages of not affecting
> !     other hosts on the same link.  But in some cases(e.g., during the
>      Queries on startup)using unicast Query instead of multicast
> !     Query, the number the valid multicast receiver on the same link may
>      be large, i.e., numerous Queries will be generated for each member,
>      which will not be an efficient use of link resources.  In this case
>      the normal multicast Query will be a good choice because only one
> ***************
> *** 853,859 ****
>      according to the practical network conditions.  For example, if the
>      receiver number is small, the router could send unicast Queries
>      respectively to each receiver to solicit their membership states,
> !     without arousing other host which is in the dormant state. when the
>      receiver number reaches a predefined level, the router could change
>  
>  
> --- 935,941 ----
>      according to the practical network conditions.  For example, if the
>      receiver number is small, the router could send unicast Queries
>      respectively to each receiver to solicit their membership states,
> !     without waking other dormant hosts. when the
>      receiver number reaches a predefined level, the router could change
>  
>  
> ***************
> *** 866,871 ****
> --- 948,964 ----
>      to use multicast Queries.  The router could make the switching
>      flexibly according to practical conditions to improve the efficiency.
>  
> + weesan: can you propose new variables or an equation for this?  For
> +         example, let's say the number of byte for the Queries is Q,
> +         the number of hosts being explicitly tracked is H, and the max
> +         bandwidth of a certain type of the wireless is B, then:
> + 
> + if (Q * H >= B)
> +     use multicast query
> + else
> +     use unicast query

[Qin]: Sounds good idea, we will try to reflect this in the new version. 

> + 
>  5. Security Considerations
>  
>     They will be described in the later version of this draft.
> --------- end diff ---------