Re: [magma] Igmp Group-Source specific Retransmission

"K.Kawaguchi" <kawaguti@ysknet.co.jp> Fri, 04 June 2010 02:06 UTC

Return-Path: <kawaguti@ysknet.co.jp>
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76CE3A6870 for <magma@core3.amsl.com>; Thu, 3 Jun 2010 19:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.105
X-Spam-Level: **
X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, J_CHICKENPOX_53=0.6, RELAY_IS_203=0.994, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wswZpoZzh+3r for <magma@core3.amsl.com>; Thu, 3 Jun 2010 19:06:45 -0700 (PDT)
Received: from tkns.tk.ysknet.co.jp (tkmx.tk.ysknet.co.jp [203.180.172.16]) by core3.amsl.com (Postfix) with SMTP id 4547F3A6782 for <magma@ietf.org>; Thu, 3 Jun 2010 19:06:44 -0700 (PDT)
Received: (qmail 7649 invoked from network); 4 Jun 2010 11:06:23 +0900
Received: from (HELO PrecisionM20) (@) by with SMTP; 4 Jun 2010 11:06:23 +0900
To: bharat_joshi@infosys.com, deepak.kudachi@hp.com
From: "K.Kawaguchi" <kawaguti@ysknet.co.jp>
References: <BF084A81AE527F4FB1447EA170E8A76547AEB1F894@GVW1157EXB.americas.hpqcorp.net> <31D55C4D55BEED48A4459EB64567589A102A09B227@BLRKECMBX02.ad.infosys.com> <BF084A81AE527F4FB1447EA170E8A76547AEB1FCF7@GVW1157EXB.americas.hpqcorp.net> <201006040922.JHD95874.HBJXBVUL@ysknet.co.jp> <31D55C4D55BEED48A4459EB64567589A102A09B230@BLRKECMBX02.ad.infosys.com>
In-Reply-To: <31D55C4D55BEED48A4459EB64567589A102A09B230@BLRKECMBX02.ad.infosys.com>
Message-Id: <201006041106.DJH87599.LVBXBUHJ@ysknet.co.jp>
X-Mailer: Winbiff [Version 2.51 PL2]
X-Accept-Language: ja,en,zh
Date: Fri, 04 Jun 2010 11:06:29 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: magma@ietf.org, sankaran.balaji@hp.com
Subject: Re: [magma] Igmp Group-Source specific Retransmission
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2010 02:06:53 -0000

Hi Bharat-san,

> now at time  interval T2 < (T1+LMQI)
> we received TO_EXC{ S1 , S2, S5 } on same interface for the same group G1.

This report desires source 'S3'.

Best Regards
--
Kiyoaki Kawaguchi


"Bharat Joshi <bharat_joshi@infosys.com>" wrote:

> Hi,
> 
>        I am not sure if I understand this correctly. 'S' bit flag needs to be set only when a querier wants to tell non-querier to not-to-update their timer. It is set when someone replies to the first query saying that he still wants that source and a source timer is updated. In this case, 'S3' will not be available in the final include source list so why should the 'S' flag be set for this source?
> 
> Thanks,
> Bharat
> ________________________________________
> From: K.Kawaguchi [kawaguti@ysknet.co.jp]
> Sent: Friday, June 04, 2010 5:52 AM
> To: deepak.kudachi@hp.com
> Cc: sankaran.balaji@hp.com; Bharat Joshi; magma@core3.amsl.com; magma@ietf.org
> Subject: Re: [magma] Igmp Group-Source specific Retransmission
> 
> Hi Deepak-san,
> 
> I comment only one point.
> Please observe S flag. (RFC3376 4.1.5.)
> 
> 
> ""Kudachi, Deepak S" <deepak.kudachi@hp.com>" wrote:
> 
> > Hi Bharat,
> >
> > I am still not clear on the part that you said all the queries have different src addresses.
> >
> > May be I can give an example for this case.
> >
> > Let us assume following values.
> >
> >
> > Robustness = 2
> > LMQI = 10 sec
> >
> > Group = G1 = 224.0.2.1
> > Srouces
> >         S1 = 10.10.10.10
> >         S2 = 10.10.10.20
> >         S3 = 10.10.10.30
> >         S4 = 10.10.10.40
> >         S5 = 10.10.10.50
> >
> > Our interface's current state is INCLUDE for group G1.
> >
> > So
> > INCLUDE{S1,S2,S3,S4} for G1
> >
> > Now we received Block message for the same group on same interface
> >
> > Consider the message received is
> > BLOCK {S3}.
> >
> > now according to RFC 3376 sec 6.4.2
> > INCLUDE (A)    BLOCK (B)    INCLUDE (A)             Send Q(G,A*B)
> >
> > We need to send a group-source specific query for A*B
> > which is nothing but send a query for source S3.
> >
> > So query will be sent at Time = T1
> > Send Q(G1, S3)
> > We have started the timer (LMQI)10 sec with repeat 1 so that
> > When timer expires we need to send one more query for this G1,S3.
> > ( query is send out for group G1= 224.0.1.2 ,S3 = 10.10.10.30.)
> >
> > now at time  interval T2 < (T1+LMQI)
> > we received TO_EXC{ S1 , S2, S5 } on same interface for the same group G1.
> >
> > Now according to RFC following function need to be performed.
> > INCLUDE (A)    TO_EX (B)    EXCLUDE (A*B,B-A)       (B-A)=0
> >                                                     Delete (A-B)
> >                                                     Send Q(G,A*B)
> >                                                     Group Timer=GMI
> >
> >
> > Interface moves to exclude mode
> > EXCLUDE { (S1,S2),(S5)} for group G1.
> >
> > Now immediate query has to be sent for S1,S2.
> >
> > Since S3 retransmission is still pending we need to merge S3 with S1,S3 in this query.
> > Now Q(G1,S1,S2,S3) will be sent at interval T2.
> 
> Q(G1,S1,S2)w/SFlag=0 and Q(G1,S3)w/S Flag=1
> 
> 
> >
> > Now for S3 we have sent two queries and its query count is set to 0 and will be
> > removed from retransmission list.
> >
> > For S3 we sent out second query much before T1+LMQI and no more queries will be sent for S3.
> >
> > This is what we infer from the RFC and just want to know others view on this.
> >
> > (please Note: I am only considering router side processing).
> >
> >
> > Thanks and Regards
> > Deepak
> >
> > -----Original Message-----
> > From: Bharat Joshi [mailto:bharat_joshi@infosys.com]
> > Sent: Wednesday, June 02, 2010 6:07 PM
> > To: Kudachi, Deepak S; magma@core3.amsl.com; magma@ietf.org
> > Subject: RE: [magma] Igmp Group-Source specific Retransmission
> >
> > Deepak,
> >
> >       It would be better if you handle the example with IP addresses. Also consider how the state in the hosts are and what final state should be there after things stabilize.
> >
> >       For the below example, I think you should attach the robustness count as query count with the source addresses and then as and when timer fires, you prepare a group-source specific query, send it out and reduce the query count for each source address you include in the query. Once the query count for a source address reaches zero, it is removed from the list and when all sources are removed from the list, we do not restart the timer.
> >
> >       So we will end up sending three queries. But all the three queries will carry different sources in the list.
> >
> >       I hope this helps.
> >
> > Regards,
> > Bharat
> > ________________________________________
> > From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kudachi, Deepak S [deepak.kudachi@hp.com]
> > Sent: Wednesday, June 02, 2010 5:50 PM
> > To: magma@core3.amsl.com; magma@ietf.org
> > Subject: [magma]  Igmp Group-Source specific Retransmission
> >
> > Hi All,
> >
> > I was going through the IGMPv3 RFC 3376  and was not clear on the below
> > Mentioned section.
> >
> > /*---------------------------------------------------------------------------------------------------------*/
> > 6.6.3.2. Building and Sending Group and Source Specific Queries
> >
> >    When a table action "Send Q(G,X)" is encountered by a querier in the
> >    table in section 6.4.2, the following actions must be performed for
> >    each of the sources in X of group G, with source timer larger than
> >    LMQT:
> >
> >    o Set number of retransmissions for each source to [Last Member Query
> >      Count].
> >
> >    o Lower source timer to LMQT.
> >
> >    The router must then immediately send a group and source specific
> >    query as well as schedule [Last Member Query Count - 1] query
> >    retransmissions to be sent every [Last Member Query Interval] over
> >    [Last Member Query Time].  The contents of these queries are
> >    calculated as follows.
> > /*-----------------------------------------------------------------*/
> >
> >
> > This section talks about how the group-source specific queries are build and
> > Send out.
> >
> > Suppose our robustness variable is set to 2(default value).
> > And Last Member Query Interval is 10 Sec.
> >
> > Any group-source specific query need to be transmitted robustness number of times
> > That is 2 times in our case and separated by LMQI which 10 sec.
> > So 2 queries has to be sent across Last Member Query Time which is 20 sec.
> >
> >
> > Now suppose we already sent Q(G,X) query for a group at T1 with set of sources. And we received
> > A report which causes new Q(G,(X+Y)) needs to be sent and T2( before T1+LMQI). Where Y is new set of sources to be
> > Queried. New Query will be sent with all sources merged from previous and new(x + y).
> >
> > So the sources x already two queries will be sent and not separated by LMQI in this scenario.
> >
> > My question is whether we need to send one more query after LMQI ( at T1+LMQI) for x
> > Set of sources for this group?
> >
> > If we need to then we will be sending 3 queries for x set of sources as follows.
> >
> > Time interval T1
> > Time interval T2
> > Time interval T1+LMQI
> >
> > Which is not correct.
> >
> > Let me know whether we should send query for x set of sources for this group
> > At T1+LMQI interval.
> >
> > Thanks and Regards
> > Deepak
> >
> >
> >
> >
> > _______________________________________________
> > magma mailing list
> > magma@ietf.org
> > https://www.ietf.org/mailman/listinfo/magma
> 
> 
> Best Regards
> --
> Kiyoaki Kawaguchi
> 
> 
>