Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard

From: Bill Fenner <[email-masked]>
Date: Thu, 13 Jul 2000 12:57:26 -0700

>	Does IGMPv3 currently support any interface (perhaps 1 bit,
>or..) such that a receiver can say 'join to the SPT directly' even if the
>underlying protocol supports a center (i.e., RP for PIM-SM) ?
>or anything to that effect?

This is supported only implicitly.  Consider a stub network, for
simplicity.  If a host sends an inclusion report for a single source
for a group, and there are no other memberships on the network, the
router is free to choose (e.g. via locally configured policy) whether
to send a (*,G) or (S,G) join.

One of the purposes of IGMP is to seperate the knowledge of the routing
protocol from the hosts.  If hosts have to know about shared or source
trees, that kind of blurs that seperation a little.  Do you see a real
gain by allowing the host to request vs. allowing the router to decide?

  Bill

---

From: helmy <[email-masked]>
Date: Thu, 13 Jul 2000 14:23:22 -0700 (PDT)

> gain by allowing the host to request vs. allowing the router to decide?

Bill,

	I agree with the separation and that the host need not know about
mechanistic details of the underlying multicast. But still, leaving the
policy up to the router may lead to degradation of performance if the
policy does not conform to the requirements of the application joining the
group... 
	so, instead of having this 'bit' or field indicate 'SPT' or shared
tree [which is multicast routing knowledge], we can have it specify some
kind of quality indicator [like low delay, or low overhead, for
example]. This would then be translated by the router according to the
multicast routing and the quality that can be provided.
	Currently, applications (or end point protocols) that use
multicast, have no control over the quality presented by the underlying
multicast (even if the service already exists, such as low delays thru
SPT, for example).

hope that makes my point clearer,

Regards,
-Ahmed