Subject: IGMPv3 individual host membership and report suppression

From: Isidor Kouvelas <[email-masked]>
Date: Mon, 19 Jul 1999 15:16:23 -0700

I have a couple of comments on the latest IGMPv3 draft regarding
individual host membership tracking and the lack of report suppression. I
am proposing the addition of a flag in the v3 query message to solve the
following problems.

My first point is with individual membership tracking for each host on a
LAN. The draft states in section 5.2.1 that a querier that tracks
separately the membership requirements of each host may omit implementing
Group and Group-and-Source Queries.

One notable advantage of individual membership tracking is that it can
result in very fast leave notification when the last member of a group
departs. This is a requirement for efficient operation of prospective
multicast applications.

On LANs with multiple connected routers, if the querier tracks membership
individually but other routers don't, incorrect membership state can
result in the routers that do not implement individual tracking. This can
happen when receiving a report to remove a source or a group as routers
that do not have individual host state will not know that there are still
active receivers. As the report will not be followed by a query for the
group or source, they will only find out after the next general query is
sent. Because there is no information in the Query packet to indicate if
the querier is implementing Group and Group-and-Source Queries, such a
condition cannot be automatically detected.

My second comment has to do with the lack of report suppression from the
v3 draft. Although many current networks are switched at the edges,
scenarios with multi access LANs and large number of hosts listening to
the same group can be envisaged. I think that stating in 5.1.3 that hosts
do not perform suppression is inflexible and introduces significant
bandwidth overheads in such cases.

I understand that the general case for suppression is fairly complex to
specify but the common case (almost all applications I can think of) will
be that a number of hosts on the same LAN listening to the same group will
have the same filter and source list requirements. As a result suppressing
reports when exactly matching reports are received should cover most cases
and is not too hard to implement.

To make the required checks more efficient it would also be beneficial to
have sorted source lists in reports. Is there any particular reason why
source lists can be in any order? It is trivial to sort such a list when
building the interface state after a user request and only needs to be
done once per request.

To permit individual membership tracking and suppression to coexist, a
simple modification has to be made to the IGMP query message. The proposed
modification can solve the tracking inconsistency problem in my first
point while enabling report suppression if the number of receivers is
large.

The proposal is to add a flag to the query message to indicate if the
querier is tracking membership individually and omitting Group and
Group-and-Source Queries.

When this flag indicates that individual tracking is performed by the
querier, reporting hosts will not be allowed to perform suppression. Other
routers on the LAN that cannot implement individual tracking can also
detect the miss-configuration using this flag and issue a warning message.

When the flag indicates that the querier is not performing individual
tracking, then none of the other routers on the LAN should do it either.
In addition reporting hosts MUST suppress exact reports and MAY also
suppress when superset reports are received if their implementation
supports it.

In a querier that can implement individual tracking of membership, the
setting of this flag can be adaptive. It can start off by tracking
individually and if the number of reports exceeds some threshold, a switch
to suppression mode can be triggered. Unfortunately this switch cannot be
per group as the flag has to be advertised in general queries.

Does this sound like a workable solution?

thanks
Isidor

---

From: Brad Cain <[email-masked]>
Date: Fri, 23 Jul 1999 19:16:53 -0400

> departs. This is a requirement for efficient operation of prospective

yes

> condition cannot be automatically detected.

good point... we probably need a bit or something to detect
misconfigurations

> and is not too hard to implement.

true, but actual implementations should have complete suppression
rules... these were specified in the -00 draft, but we wanted to
simplify the protocol

another reason we thought that it wasn't such a big deal is that
many networks are moving to switched architectures... 

> source lists can be in any order? 

yes...

we didn't want to make it an absolute requirement, although for 
efficiency reasons, you would probably code it this way... i can't
remember any specs which mandate such ordering... is there a 
precedent for this?

> Group-and-Source Queries.

yes... (i was thinking the same above)

> Does this sound like a workable solution?

thanks for pointing out an oversight

brad