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

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Jun 2010 13:08:11 -0700

Hi

I've read through your draft and think it is a good starting point for a
wg draft on this topic.

I believe more work is needed, but I find that the current document has
some analyzes of many interesting issues. The analyzes should be
extended on some points, and maybe also some more concrete
recommendations, but it's a good starting point.

Below are some comments on part of the text. I may have some more issues
and comments later. Text from the draft is indented.

Section 2:

    use. Current IGMPv3 and MLDv2 provide the reliability for these
    messages by simple retransmission, which is not adequate from both
    the robustness and efficiency aspects [ROBUST]. This issue can be
    enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK].

I think this statement is a bit too strong. Whether it is adequate
depends on the scenario.

    In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to
    suppress duplicated multicast listener reports on the link. In
    IGMPv3 and MLDv2 host suppression mechanism is removed. Instead,
    Explicit Tracking for per-host tracking is adopted.

It sounds like Explicit Tracking is mandatory with IGMPv3/MLDv2, but
it is only optional. The following paragraph is fine, where you write
that it is possible to do tracking.

Section 3.1:

    O Various types of links: Wireless link is usually asymmetrical link
       and is restricted to unidirectional data retransmission. The
       performance also varies with each link type.

I must say I'm a bit unsure about this one. In particular whether the
links are usually asymmetrical, and the "unidirectional data
retransmission".

One thing that maybe can be mentioned somewhere is that some link
types provide better reliability for unicast than multicast. E.g.
link-layer acks and retransmissions for unicast but not multicast.

    O Increased Leave Latency: Unlike wired multicast, the leave latency
    in the wireless multicast will be increased with user movement.

I guess this is latency as seen by the network?

4.1.1:

    O Reducing Power consumption: Due to elimination of the suppression
    of multicast listener reports, the host does not need to hear and
    suppress the duplicated report message which is beneficial to mobile
    hosts that do not have enough battery power.

I don't get this. Suppression of reports would save battery power since
fewer reports are received and you may not have to send your own. Or
your point is that sending your own report is cheaper than receiving
other's reports which is needed if you do suppression? Anyway, it is
not clear to me.

4.1.3:

    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 intercept and response to IGMP/MLD Queries packets
    sent by upstream router. Typically this means that the router will:

What to do you mean with a router intercepting queries and responses.
Normally you would just do IGMP/MLD at the edge and do say PIM between
the routers. Are you discussing the IGMP/MLD proxy case here?

    - Never send a specific query to any client, and

    - Forward general queries only to those clients receiving at least
      one multicast group

What do you mean by forwarding queries?

4.1.7:

Are you suggesting using specific queries instead of general queries?
How would that work? What if you missed the unsolicited report from a
host joining a new group?

Stig

---

From: Qin Wu <[email-masked]>
Date: Wed, 09 Jun 2010 15:51:38 +0800

Hi, Chair:
Thank you for spending time reviewing this I-D and indicating your support being wg draft. I agree although 
many of detailed issues specified in this I-D need further extending and polishing, the structure of this document
 has been in good shape.:-)  Hope to hear more discussions on this topic and get this work moving forward.
As regarding your valuable comments, please see my reply belows and check whether I have addressed your
concerns.

Regards!
-Qin

----- Original Message ----- 
From: "Stig Venaas" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 09, 2010 4:08 AM
Subject: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt

> I think this statement is a bit too strong. Whether it is adequate

[Qin]: Good point, How about
"
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].
"

> that it is possible to do tracking.

[Qin]: Okay. We could say
"
In IGMPv3 and MLDv2, this suppression of host membership
 reports is removed. This is mainly because multiple 
group records can be reported in one message in IGMPv3 
and MLDv2 which brings the advantage of decreasing the 
number of packets sent. Also, Explicit Tracking for 
per-host tracking can be adopted in IGMPv3 and MLDv2 
as one optional feature to further decrease the 
number of unnecessary packets sent.
"
What do you think of it?

> links are usually asymmetrical, and the "unidirectional data

[Qin]: I agree. Acutally what I really want to say is wireless link for multicast is possible asymmetrical link
and/ or unidirectional link. That is to say, from the multicast data delivery perspective,
the multicast data will be only sent from router to the host, not the other way around. So we could
say
"
Wireless link for multicast is possible asymetrical link
 and is restrict to unidirectional data retransmission.
The performance also varies with each link type.
"

> link-layer acks and retransmissions for unicast but not multicast.

[Qin]: Good suggestion. How about saying:
"
    O Various types of links: Wireless link for multicast is possible asymmetrical link
       and is restricted to unidirectional data retransmission. The corresponding
       performance also varies with each link type.  Also some link types provide better 
       reliability for unicast than multicast, e.g., by unicast retransmission.
"
What do you say?

> I guess this is latency as seen by the network?

[Qin]: You are right. Normally inthe wired network, user will not move or change the device.
But this is not in wireless network.

> other's reports which is needed if you do suppression? Anyway, it is

[Qin]: I guess you misunderstand what I said here. The clarification I have is:

With the host suppression, the host MUST spend processing power all along to
listen and determine whether there are duplicated report message, which 
require the host to consume too muchmore power to do this. But from the router perspective,
the router may benefit from this host suppression, becos, a certain number 
of duplicated reports are suppressed, which may save lots of processing power 
for the router.

On the other hand, if we remove host suppression, then the host does not need
to spend any processing power to listen and determine whether there are
duplicated report message. The cost may be the router need some process power 
to process the reporet unsuppressed. Fortunetely , this is not issue for the router.
becos the multicast group records can be carried in one compound report messages
which decrease unnecessary report to the routers.

Does this clarify?
 
> the routers. Are you discussing the IGMP/MLD proxy case here?

[Qin]: The router intecepting queries is one intermediate router between the host and
router. This router may also provide explicit tracking function. In this case, the router 
does not need to forward the queries to all the hosts behind itself. becos, the router
know whether there are listeners on the downlinks with explicit tracking function, therefore 
the router can response to the queries from upstream routers on behalf of these listeners. 
Here the intermediate router can be looked on as proxy described in RFC 4605. This case 
is applicable especially when there are several hops between the host and the upstream router.
The intermediate router can sit at DSLAM between the host and the upstream router.

> What do you mean by forwarding queries?

[Qin]: Good question. Let me give you one example below.
Suppose there are three hosts sitting behind this intermediate router (i.e., DSLAM),
Host A and Host B only join multicast group 1 through this intermdiate router, Host C not only join multicast
group 1 and multicast group 2. In this case, the router has three host interfaces which respectively corresponding
to Host A, Host B and Host C. then the router only send the General Query message to the host  interface that is
corresponding to the Host C. That is what we called forwarding queries.

> host joining a new group?

[Qin]: Not exactly. Using specific queris instead of general queries depend on the sceanrio you are looking at.
In the case mentioned in 4.1.7, when the the number of receivers on the link is large, we can use specific queries
instead of sending general queries.The main incentive to use specific queries instead of general 
queries is to avoid solicited report bursts due to general queries recieved by large number of hosts at the same 
time. Let me give you one example to explain how it works.
Suppose 500 hosts sitting behind the same upstream router belong to five different multicast groups, each multicast group
has 100 users.
If the router send only one General Query to all these 500 hosts, these hosts may repond with 500 reports at the same time
when response delay for the hosts is poorly set , which may cause serious packet bursts.
Instead, if we send five group specific Query to each 100 hosts with 100ms interval, 200 ms interval, 300ms interval,400ms interval,
500ms interval respectively. each 100 hosts may receive the Group Specific Query at the different time interval, which can greatly 
decrease the possibility to occur packet burstiness.

Also If we allow IGMP/proxy sit between the hosts and the router, the proxy can stop forwarding Group specific Query to the hosts.
which also can avoid packet burstiness.

As regarding unsolicited report missing you raised, I belive it is not related to this case in 4.1.7. Becos the unsolicited report will not
be used to respond to the General Query and Group Specific Query. The reports that may result in packet burstiness here is solicited 
reports.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Jun 2010 10:34:15 -0700

> As regarding your valuable comments, please see my reply belows and check whether I have addressed your

Just to be sure, I think I should make some clarifications here so that
we are all on the same page. I think you may be reading more into it
than I intended.

My comments should be regarded as coming from any member of the working
group. And the opinions of a single wg member does not really count for
much. For wg decisions there must be a rough consensus.

I wrote that it is a good starting point for a wg draft on this topic.
Since we have at least one other draft on the same topic, this does not
necessarily imply that I think we should adopt your document. Note, I'm
not saying we should not either, all I'm saying is that it doesn't imply
that.

But again, my opinion on this is not worth more than the opinion of any
other individual in the wg.

I'm hoping that my input can help stimulate discussion of your document
in the wg. If you get input from the wg and you update your document
based on that, then hopefully the quality would improve further, and
also probably more support for your document in the wg.

Even though it is a good starting point, there is a lot of work to do.

See inline below.

> enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK].

Yes, that is better.

> number of unnecessary packets sent.

Maybe say something like: That there is no suppression, also
allows for explicit tracking of host memberships.

Or something like that. At least they key is that explicit
tracking is possible, and as you say, an optional feature.

> The performance also varies with each link type.

It's possible for hosts to send multicast data on a wireless link
too. Maybe you don't need to say anything about this. At least for
the MLD/IGMP discussion you only care about receiving multicast
data (apart from the MLD/IGMP messages that also are multicast).

>        reliability for unicast than multicast, e.g., by unicast retransmission.

Yes, this is better. But I still don't necessarily agree about the
unidirectional part. At least not in general. There are wireless
links that are not unidirectional, but I'm not surprised if there
are some links that behave as you say.

> which decrease unnecessary report to the routers.

Yes. So good if the text in the document can go into some more detail.

> The intermediate router can sit at DSLAM between the host and the upstream router.

OK, I think you need to explicitly talk about IGMP/MLD proxying then.
And use a different term than "intercept". The proxy is listening to
the appropriate IGMP/MLD-groups and receives the reports similar to a
multicast router. Then based on the aggregate state it sends messages
upstream.

> corresponding to the Host C. That is what we called forwarding queries.

I still don't think I get it. But, if you talk about MLD proxies, then
they may send general queries downstream, independently of when the
upstream sends them. So it is not forwarding.

There is also the term MLD snooping which would be close to what you
describe, but that is also different.

> be used to respond to the General Query and Group Specific Query. The reports that may result in packet burstiness here is solicited 

My point is that you cannot just do specific queries instead of general
queries. My concern is that if the router never received an unsolicited
report from the host, then the router can only learn about that group if
it sends a general query (unless perhaps if another host joins the same
group). If you don't do general queries, you only learn about new groups
from unsolicited reports, and if you miss some of those reports...

I hope others can contribute to the discussion of these and other
points.

Stig

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 Jun 2010 20:00:02 +0800

Hi,Stig:
Thank for your justification. I value your open opinion and believe we need more volunteers to
produce good review and move this work on. Also I would like to thank for your effort on 
helping stimulate the discussion to this document.
Here is my reply belows.

Regards!
-Qin
----- Original Message ----- 
From: "Stig Venaas" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 10, 2010 1:34 AM
Subject: Re: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt

>> enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK].
 
[Qin]:Okay, thanks.

> tracking is possible, and as you say, an optional feature.

[Qin]: I like your proposal, we could say:
"
In IGMPv3 and MLDv2, there is no such host suppression 
and explicit tracking of host membership is allowed, which 
can be used to decrease the number of unnecessary packets 
sent.
"

> data (apart from the MLD/IGMP messages that also are multicast).

[Qin]: Right, also I realize in the wired network, it is also possible to have one asymmetric link which has
different rates for the upstream direction and downstream direction. Therefore I propose to remove the
bullet 1: Varous types of links from Section 3.1.
And I would like to incorporate your proposal
"
Also some link types provide better 
reliability for unicast than multicast, 
e.g., by unicast retransmission.
" 
into bullet 5: Reliability as
"
o Reliability: 
In various type links, some link types provide better reliability 
for unicast than multicast, e.g., by unicast retransmission. 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. 
"
 Are you satisfying with this?

> are some links that behave as you say.

[Qin]: See above.

> Yes. So good if the text in the document can go into some more detail.

[Qin]: Okay. And will update it into the next version.

> multicast router. Then based on the aggregate state it sends messages

[Qin]:  This is what we said in the previous section 4.1.2 "Report suppression". In other words,
In the section 4.1.2, membership report can be aggregated together into a
single membership report, which save lots of processing power for the upstream router.

But in the section 4.1.3, we discuss another case, i.e, "Query Suppression", In this case,
"Intercept" actually means "Stop Forwarding". The example is:
Queries may be sent from hundreds of different upstream routers, but passing through
the same downstream router sitting between the hosts and the upstreams routers to the hosts.
 In order to reduce unnecessary Queries sent to the hosts, the downstreams router who acts as proxy
can filter out the queries sent to the hosts behind itself and respond with reports to the upstream routers.

If you agree with this, we could reword the section 4.1.3 as follows:
"
4.1.3. Query Suppression for the routers
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 stops forwarding IGMP/MLD Queries packets sent to the hosts 
and responds with report as IGMP/MLD proxy to the upstream router. Typically this means that the router will:
"

> describe, but that is also different.

[Qin]: Probably you are right.
Actually we are discussing  selective sending the Query to the hosts in this case, which could be supported by MLD snooping functionality.
If you like, we can change 
"
Forwarding general queries ...
"
into 
"Selective send general queries...." or just "send general queries"

> from unsolicited reports, and if you miss some of those reports...

[Qin]: Good point. Sorry for my early misunderstanding.
That is to say, if we use Group Queries to replace 
General Queries, in some cases, we may miss lots of solicited report which is early used 
to do membership state update and new group collection on the router. In worse case, unsolciited reports are also losted
due to bad link condition, which will cause some new group information can not be collected by the router.

Therefore the limitation of this case is we should guarantee that the unsolicited report will not be lost. Right?
With this limiation, do you have any proposal? Remove this case in 4.1.7 or add some text in 4.1.7 to explain this limitation?