Subject: Newbie IGMPv3 questions

From: Selina Priestley <[email-masked]>
Date: Wed, 21 Feb 2001 15:01:38 -0500

Hi there,

I have some questions about the IGMPv3 draft.  I think only the first
one isn't language-related.

1. I am wondering about the behavior of a router which has EXCLUDE filter
   mode for a group which receives a Current-State Record of IS_EX.
   
   Here's the notation from the draft (in 6.4.1):
   
      EXCLUDE (X,Y)  IS_EX (A)     EXCLUDE (A-Y,Y*A)        (A-X-Y)=GMI
                                                            Delete (X-A)
                                                            Delete (Y-A)
                                                            Group Timer=GMI
   
   My question is about Y-A.  It seems from my reading that there could
   still be other systems out there which do not want to hear about Y-A.
   It looks like if those systems generate responding Current-State Records 
   on the long side of the max response time and the system which sent the 
   is_ex responds quickly within the max response time, then those systems 
   which don't want to hear Y-A may have to do so again for up to 10 
   seconds (using default MRT).  Am I misreading somehow?  The same
   situation exists for EXCLUDE/TO_EX.
   
2. In 6.2.3, it says

      When a router filter-mode for a group is EXCLUDE, source records are
      only deleted when the group timer expires.  Section 6.3 describes 
      actions that should be taken dependent upon the value of a source timer.
    
   However, 6.4.1 and 6.4.2 go on to describe situations where a 
   source record is deleted while the group timer is still running.
   Maybe this means the below instead?:
      
      When a router filter-mode for a group is EXCLUDE, source records are
      not deleted when the associated source timer expires.  Section 6.3 
      describes the actions that should be taken dependent upon the value 
      of a source timer.

3. Also in 6.2.3,

      Source timers are
      always updated (for a particular group) whenever the source is present
      in a received record for that group.  Section 6.4 describes the setting
      of source timers per type of group records received.
      
   Again, in some cases in 6.4, source records are deleted although present
   in the received record.  I suppose this could count as 'updated', but it
   just doesn't seem right.  (It also looks like A*B doesn't get it's timer
   updated in the INCLUDE(A)/IS_EX(B) case, but maybe that's a typo).  I'm 
   not sure what this paragraph is trying to get across, so don't have a 
   suggested alternative.  

Finally, if it's the case that Group and Group-and-Source Specific Queries
aren't sent in response to Current-State Records because these records are
themselves responses to General Queries, it seems like it would be good
to make note of that, rather than just stating that Group and Source
specific queries are never sent in response to Current-State Records, as 
stated in 6.1.  Also, why make that point for Group-and-Source Specific 
and not for Group-Specific?  I think I might break out that last paragraph 
of section 6.1 at the last two sentences and add the two points just above
(if they're true, that is).  Or just delete the phrase 'and never in response 
to Current-State Records'.

Thanks a lot,

Selina

P.S. In the case of the deleted Y element mentioned in 1. above, it seems
like a source specific query or keeping that Y around for MRT (even 
forget robustness time) would be a good thing.  Why are these two responses 
bogus?  :-)  I am thinking about the case where the deleted Y source is
sending something really heinous.

---

From: Rolland Vida <[email-masked]>
Date: Thu, 22 Feb 2001 10:35:13 +0100

Selina,

Here are a few answers to your questions. It is essentialy how I see things, the
authors of the draft might confirm it or not.

>    situation exists for EXCLUDE/TO_EX.

The idea was to minimize the list of sources that are kept at the router. If this
list is often modified (following consecutive Current State Records for example)
is not a problem as long as the source list is kept small. If data from a source
that no one wants to hear about passes the router's filter, there's no problem, it
will be dropped later. The only concern is to do not cut off sources that might
have interested receivers.

>       describes the actions that should be taken dependent upon the value

You have a point here, as section 6.2.3 discusses the actions related to the
expiration of source timers, and not the group timer.  What the authors probably
wanted to say is that if the source timer expires while the filter is EXCLUDE, the
source record is not deleted (as in the INCLUDE case), it only passes in the set
of unanimously unwanted sources. It is true though that source records could be
deleted following other events such as the reception of some reports, so your
phrasing might be more correct.

>    just doesn't seem right.

I do not see which case you are talking about. There's no case when a source
record is deleted while present in a received record....

>  (It also looks like A*B doesn't get it's timer
>    updated in the INCLUDE(A)/IS_EX(B) case, but maybe that's a typo).

It is true that A*B doesn't get it's timer updated in this case, and it should not
to! So maybe the phrasing in section 6.2.3. should indeed be modified a bit.

Regards,

Rolland Vida

--
______________________________________________________
Make everything as simple as possible, but not simpler - Albert Einstein

Rolland VIDA - Ph.D. student
Universite Pierre et Marie Curie
Laboratoire LIP6-CNRS, 8, rue du Capitaine Scott
Tel: +33 (0) 1 44 27 71 26              Fax: +33 (0) 1 44 27 74 95
E-mail: [email-masked]           Web: http://www-rp.lip6.fr/~vida
______________________________________________________

---

From: Rolland Vida <[email-masked]>
Date: Thu, 22 Feb 2001 19:27:31 +0100

Selina,

> This was my take as well.  However, I wonder how good an idea it is
> to start announcing proscribed sources again when no one has specifically
> asked for them.  I am thinking about parental controls, or some really
> noxious site.  It would be difficult to guarantee a customer that they
> would not see the things they didn't want to see.  And difficult to keep
> teenagers from rigging some IS_EX box up to see 10 seconds of whatever
> every small space of time.  I guess it's a matter of how you build this..

IGMP is a soft state protocol, so you have to confirm from time to time sources
that you do no want to hear from. This is particularly useful in the case of a
router being in EXCLUDE filter mode. If no one confirms its excluded source list,
the group timer will expire and the router will switch back to INCLUDE mode, so it
will alow to pass much less sources then before.
On the other hand, even if a source's packet gets behind the router, it will not be
delivered to the receiver if it is a forbidden source. Hosts keep socket state and
interface state, with their local filters and source list. So if an incoming packet
does not fit in the local requirements, it will not be delivered to the requesting
socket.
On the end systems, source lists are kept without associated timers, so they will
not time out. The source list could be modified only be a new invocation of
IPMulticastListen. So once the parent filtered out the malicious sources, state
will be maintained locally, and packets won't be delivered.

> Hm.  Why would A*B not get updated in INCLUDE(A)/IS_EX(B), but the
> A-X-Y does get updated in EXCLUDE(X,Y)/IS_EX(A)?  It seems like in
> both cases someone asked not to hear those elements.

There's a difference. When in INCLUDE(A)/IS_EX(B), A*B is not updated, as sources
from A have running timers smaller than GMI at the moment the report arrives.  So
if someone still listens to a source from A*B, it should confirm its interest
before this timer expires. By not updating the timer we reduce the interval after
which these sources will pass in the second set of unanimously unwanted sources.
The case when in EXCLUDE(X,Y)/IS_EX(A) is different.
Let's start with the following equation: X+A+Y=(X-A)+(X*A)+(A-X-Y)+(Y*A)+(Y-A)
X-A and Y-A will be deleted.
Sources from A-X-Y were not present until now in the router's list (the previous
list including X+Y) so they have to get a timer. They will be set at GMI, as they
will be part of the first set of "conflicting" sources. Sources from Y*A will stay
with their timer set to 0. Sources from X*A will not update their timers exactly
for the same reason as in the first case discussed. You should note that A-Y =
(A-X-Y) + (X*A)
In the previous version of the draft the new state of the router was described as
EXCLUDE (X*A + (A-Y), Y*A).
But it was simplified as X*A is always included in A-Y.

I hope i was clear enough... :-)

Rolland

---

From: Selina Priestley <[email-masked]>
Date: Thu, 22 Feb 2001 11:50:49 -0500

>authors of the draft might confirm it or not.

Thanks very much for your reply!  I appreciate it.  Further questions
below.

>record is deleted while present in a received record....

You know, you're right.  :)  Got my As and Bs mixed, since A does the 
samba between INCLUDES and EXCLUDES.

Thanks so much for your time!

Selina