Subject: Fw: Standardisation of IGMPv3

From: Manuel Oliveira <[email-masked]>
Date: Thu, 13 Jul 2000 20:43:54 +0100

Hi Mark,

I could not resist providing a different view on the issues you raised.

>  - It would complicate the IGMPv3 machinery (which is already pretty
>    complex) because you'd have to resolve mismatched masks.  Eg one
>    host specifies "Exclude (128.1.0.0/16, G)" another host specifies
>    "Exclude (128.1.2.0/24, G)".
Depends what you consider a mask to be. Currently we have host filtering and
address filtering. It has been mentioned time and time again that network
filtering would be useful. So we propose that instead of a mask, consider a
filter that is used for subcasting purposes. This filter represents the
aggregated interest of receivers along a particular route.

So in the case above what would happen is the following:
i) both hosts would join (128.1.2.0/G) - obs: this also works for shared
based groups.
ii) host A subscribes to flow 16
iii) host B subscribes to flow 24
The outcome would be:
i) if both hosts are on the same subnet then both get flows 16 and 24. So
filtering would be done at the host, however this would take place within
the IP stack.
ii) hosts are on different subnets then each only receives the packets they
are interested in.

The necessary mechanisms are simple boolean operations and additional state
required is negligible. These mechanisms are ortogonal to how the routing
structure is constructed and only affect the forwarding process.

>  - You also have to cope with nested include and exclude masks.  Eg
>    one host specifies "Exclude (128.1.0.0/16, G)" and another host
>    specifies "Include (128.1.2.0/24, G)".  For IGMPv3, this is additional
>    complexity.  If you want to map this into PIM this would want to map
>    into two Prune *ranges* - you can't implement this with a single
>    mask, so you'd actually need a large number Prune mask entries
>    (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G),
>    etc).
If the filter is aggregated interest then this situation does not occur.

>  - It requires the API be extended to allow apps to specify masks.
>    For exclude masks, there doesn't seem to be any practical way the
>    app can use the mask.  It's never going to be told by a misbehaving
>    sender what the correct netmask is, and it's increasingly unlikely
>    to be able to guess correctly.
Is extending the API so bad? The socket API could be extended to include the
two operations, by having two new socket options. This would not break
existing applications and would benefit applications such as online games
and distributed VR. The overhead for other application types is zero since
the filter would be non active, and all packets were forwarded.

With regards to exclude, it is all a matter of semantics. You just indicate
that you do not want any more traffic from a particular flow.

>  - If the IGMPv3 host specifies an include netmask that is too large,
>    how do you implement this in PIM?  Do you route an (S-mask,G) Join to
>    the place where the routes diverge, and then have to split the Join
>    to go multiple ways?  I guess you'd have an issue if someone
>    specifies "Include 192.1.0.0/16" for example.
As mentioned before join/leave is done in the normal fashion. The host then
indicates their interest in flows by subscribing to them, thus updating the
filter associated to their route. If there is a change to the filter then
the router is required to do an update by dissiminating the new filter along
the remainder routes. Although minor, existing routing protocols would have
to be exteneded to support this.

> In general, I think this raises too many complexities for what seems
> to me to be too little gain, so that it just doesn't seem worthwhile.
> It's likely to add significant delay to standardizing and deploying
> SSM, and that seems to be a bad tradeoff to me.
Well, we think it is simple and efficient providing a lot of benefit for
large scale applications. And it does not negatively impact other
application genres.

Application that would benefit from this filtering mechanism (top of my
head):
- layered multicast apps
- online games + distributed VR

There is a paper (unpublished) describing the idea in more detail. Myself ,
Jon or Christophe would be happy to provide it to anyone who is interested.

Cheers

Manuel

---

From: [email-masked]
Date: Fri, 14 Jul 2000 11:32:57 +0530

Hi ,
 I agree with what you say. Also, I think postponing the network level filtering to v4 would 
introduce more interoparability issues and interoparability would dominate the development 
effort of IGMPv4. Also, the routing protocols(DVMRP/PIM) have to be tailored to interoperate 
with v3 and v4 separately. Already they have to different strategies while operating with v1 and 
v2.  Hence, it would be better to incorporate net. filtering in v4 before standardising it. 

Hi Mark,

In the above situation, a simple strategy would be to the exclude for 128.1 could be cancelled 
in favor of the include because atleast one host is intersted in 128.1.2.  Although this is not 
perfect this situation occurs because of lack of aggregated interest within hosts in a subnet 
which should be avoided.

Regards,
Vijay

Enter your default signature here
Sent by Indya Messaging Service

---

From: [email-masked]
Date: Fri, 14 Jul 2000 11:05:02 +0530

So, unless someone can illustrate situations where this
would actually be useful (and where *not* having the
netmask information would be a real impediment), as well
as mechanisms to enable the group-members to learn about
the source's local prefix,  I think this feature could
be safely postponed until IGMPv4.  :-)

The idea of postponing this network filtering to v4 would introduce more interoperability issues. 
Already we have 3 versions of IGMP. If a fourth version is made just for the sake of network 
level filtering the iinteroperability issues are likely to dominate the development effort. 
I think the issue must be resolved once and for all instead of postponing it.

>   (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G),
Can't such contradicting nested mask be resolved in favor of the 'INCLUDE' mask, ie, since 
atleast one host is interested in traffic from 128.1 network the exclude for that network can be 
cancelled in favor of the include.

Regards,
Vijay