Re: Re: IGMP report suppression

Princy and Tomasz,

In response to Tomasz (Nevertheless it does not seem to me that this 
behavior is similar to behavior of  IGMPv1 and v2 because all receivers 
will sent Report message for one particular group. Not like in case of 
IGMPv1 and v2 where only one router answers per group.): 

I guess I was a little unclear here. I meant that this implementation 
could be likened to  IGMPv1 and v2 in that if a earlier version host is 
the one sending the reports (all others repress theirs), this 
host/listener/receiver would send a report out for each group, as opposed 
to multiple groups packed into one report.  My interpretation of the 5.2 
rule 1 was to simply (though less efficiently) maintain IGVPv1 & v2 
functionality and use the group timer to schedule reports. This wouldn't 
(unfortunately), as Princy put it, "pack as many current_state records as 
possible into a single report message." But it is simpler to implement. My 
last sentence, then, about report suppression still not being required if 
using this implementation was to say that: even though the reports can be 
broken up and sent separately, IGMPv3 still can not hope to repress a 
single group report because it now includes sources. 

So, just different interpretations of the rule. I suppose the best is the 
more efficient, report-packing and spreading out of these reports (which 
is not like IGMPv1 & v2).

Thanks,

Christy




Princy Elizabeth <[email protected]> 
12/14/2006 12:53 AM

To
[email protected], Christy L Norman/Rochester/IBM@IBMUS
cc
[email protected]
Subject
Re: Re: [magma] IGMP report suppression






Hi,
 
My apologies for the extreme delay in replying to this thread. I happened 
to look at the IGMPV3 RFC again just recently. 
 
IMHO, section 5.2 rule 1 that Christy referred to, suggests spreading  out 
the transmission of reports over the interval (0, Max Response Time) only 
in cases where the response to a general query results in generation of 
more than one report because all current state records cannot be fit into 
a single report due to the MTU limitation. The RFC advises packing as many 
CURRENT_STATE records as possible into a single report message and when 
the number of reports is more than 1, spread the transmission over the MRT 
interval. So even in the case where a single host is a member of an 
extremely large number of groups, IGMP V3 would still generate less 
reports (maybe 2-3 per host depending on the MTU) as compared to V1/V2 (10 
per host). I am not sure if this is what Tomasz was also implying. So 
thought of adding my interpretation also to the thread. I'd like to hear 
your views on this.
 
Regards,
Princy

[email protected] wrote:
Hello,
I hope that you do not mind that I has joined your discussion. 
I was recently studying IGMPv3 quite hard in order to get all ins and outs 
of this protocol version. I agree with the preceding speaker that in case 
of IGMPv1 and v2 reports are suppressed in order to reduce the traffic. I 
also share the view that there is no point to suppress receiver Reports 
messages in case of IGMPv3 due to the issue with sources. 

However I not quite get the intention of the second part of the email. 
Let's extend the example presented in the first reply. Assume that we have 
Ethernet segment with then receivers, ten groups and 100 sources in each 
group. As it was mentioned earlier we will have 10 Report messages in 
reply to Query message in case of IGMPv1 and v2. Each Report message will 
concern to different group. Due to report suppression only one receiver 
will answer per group and the Reports will be sent per group address.
In case of IGMPv3 situation is a bit different. All router will answer to 
Query message but they will not sent separate Report message for each 
group. Each one of receivers will sent just one Report message, on address 
224.0.0.22, containing information about reception stage for each of 10 
groups. Since there is only one message sent by receiver it has 
information about many groups. Moreover information for each group 
contains list of sources (in our case there are 100 sources so the list 
can be quite long). As a result Report messages in case of IGMPv3 are 
quite large. For that reason RFC 3376 states:
 "Instead of using a single interface timer, implementations are 
recommended to spread transmission of such Report messages over the 
interval (0, [Max Resp Time])."
Advising to not set single Report message in response to Query but divide 
it and sent it spread over some time interval. Nevertheless it does not 
seem to me that this behavior is similar to behavior of  IGMPv1 and v2 
because all receivers will sent Report message for one particular group. 
Not like in case of IGMPv1 and v2 where only one router answers per group. 
What are your views on that? Do you are with me?

Regards
Tomasz Bartczak
Christy L Norman napisa³(a):

I agree with the answer to Parit's question. IGMPv1 and v2 reports can be 
suppressed to reduce unnecessary traffic. However, in regards to the 
reason for the absence of report suppression in v3 - I believe it is due 
to the presence of sources in an IGMPv3 report. One record could easily be 
omitted from a report (record suppression?). All listeners to a group may 
have different sources making up their per-interface states and to check 
the sources of  all hosts' reports would be a bit of work for the host.   

In addition to this reason, RFC 2236 states in 5.2,  "Instead of using a 
single interface timer, implementations are recommended to spread 
transmission of such Report messages over the interval (0, [Max Resp 
Time])."  In this case, the operation will be much like IGMPv1 & v2 - but 
report suppression isn't required if you happen to be implementing that 
method of reporting - because of the issue with the sources. 

Do you agree? 

- Christy



Princy Elizabeth <[email protected]> 
11/02/2006 11:32 PM 

To
P K S <[email protected]>, [email protected] 
cc

Subject
Re: [magma] IGMP report suppression








IGMP V1 and V2 reports are sent per group. Consider a LAN with 10 hosts 
each interested in the same 10 groups. If reports suppression were not 
employed, every Query interval there would be 10 reports sent out by each 
of the 10 hosts ==> 100 reports which unnecessarily increase the traffic 
on the LAN. For the router, it is sufficient to know that there is one 
interested member for a group on the LAN. So 1 report per group would have 
sufficed. This precisely is what is done through report suppression. In 
IGMP V3, a single report can contain the report for all the groups a host 
is interested in. Thus there is no need for report suppression here since 
the number of reports would be generally, equal to the number of hosts 
only. 
 
I hope that clarifies your query. 
 
- Princy


P K S <[email protected]> wrote: 
Why is the IGMP report suppression required in the first place? 
  
Regards 
 Parit 
_______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma 
Get your email and see which of your friends are online - Right on the new 
Yahoo.com _______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma


---------------------------------------------------------------------- 
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
_______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma
_______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma

 __________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

_______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma