Subject: Questions about IGMPv3 draft

From: Bob Quinn <[email-masked]>
Date: Thu, 25 Nov 1999 12:06:13 -0500

Hi there,

I had some questions about draft-ietf-idmr-igmp-v3-02.txt
Please forgive me if these have been addressed before.

First, I'm wondering what the rationale is for having support
of "EXCLUDE" source filter mode?  The protocol would be 
substantially simpler without it and it does not seem necessary 
given that exclusion is implicit with inclusion.  Practically 
speaking, sessions are likely to have a (very) finite number 
of sources, but the number of exclusions is virtually limitless.  
What is the point?

Second, why not support wild cards for source addresses (e.g.
0.0.0.0 to denote '*')?  Not only will this simplify selection
of source sets, but it eliminates the need for exclusion filter
mode to join a group without specifying a source (i.e., (*,G)).

Third, Section A.2 provides rationale for "full-state requests"
that provide a bias for "absolute" source lists rather than
"delta" ("state-change"), but I question the motivation.  It 
unnecessarily increases application state since they need to 
maintain a list of sources.  This could be simplified a bit by 
adding a new API to query the stack for the current per-socket 
group source, but I'm not sure that "full-state" is necessary
or desirable in all requests.

The protocol itself seems to prefer the "delta" model since a 
"Source-List Change Record" provides a list of *additional* 
sources but not a complete list that "full-state" would need.  
More importantly, as stated in the 4th item, "absolute" is not 
even supported if requests are split across two or more messages 
due to MTU limitations.  Section A.2 mentions the possibility 
of a "mechanism to indicate that messages are somehow linked" 
to support "full-state requests," although no such mechanism 
exists in the protocol.  Seems like a stretch.

Considering that a single interface can have muliple sockets with
different source lists (and filter modes), an IP stack has to deal 
with "state-change" no matter what (as do routers, that handle
multiple interfaces).  As for applications, what's so difficult 
about using an API that includes a flag to indicate "state-change" 
vs. "full-state" (and another that indicates filter mode)?  Seems 
simple enough. 

Using "full-state" may well be preferred in many cases since (at
least initially) we will have finite source lists.  But in those 
instances in the future where there were a lot of sources and the 
membership is dynamic (e.g. a large DIS application), it would 
actually incur more overhead (on a host and in the message sizes).  
Since it is hard to predict what will best in the long run, it 
seems to me that having the API flag to indicate "full-state" or 
"state-change" would provide lot of flexibility without adding 
significant complexity.

That's it!  I look forward to hearing your commments and 
apppreciate your patience.

Thanks,
--
Bob Quinn
[email-masked]