Subject: Re: Re: [magma] IGMP report suppression

From: Princy Elizabeth <[email-masked]>
Date: Wed, 13 Dec 2006 22:53:57 -0800 (PST)

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-masked] 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-masked]>   11/02/2006 11:32 PM 
            To
  P K S <[email-masked]>, [email-masked]       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-masked]> wrote: 
Why is the IGMP report suppression required in the first place? 
  
Regards 
 Parit 
_______________________________________________
magma mailing list
[email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/magma

        ---------------------------------------------------------------------- 
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma
_______________________________________________
magma mailing list
[email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/magma