From deering@Pescadero.stanford.edu  Thu Feb 25 22:01:07 1988
Posted-Date: 25 Feb 1988 19:22-PST
Received-Date: Thu, 25 Feb 88 22:01:07 PST
Received: from Pescadero.Stanford.EDU by venera.isi.edu (5.54/5.51)
	id AA14960; Thu, 25 Feb 88 22:01:07 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
	id AA07801; Thu, 25 Feb 88 21:59:18 PST
Date: 25 Feb 1988 19:22-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: 4.3 multicast extensions 
To: Van Jacobson <van@lbl-csam.arpa>
Cc: end2end-interest@venera.isi.edu, karels@okeefe.berkeley.edu
Message-Id: <88/02/25 1922.540@pescadero.stanford.edu>
In-Reply-To: Van Jacobson's message of Sun, 21 Feb 88 233705 PST
Status: R

[Van - Since Bob forwarded my original message on this topic to the
end2end-interest list, I hope you don't mind me replying in the same forum.]

	From: Van Jacobson <van@lbl-csam.arpa>:

	There is one thing that bothers me: that the add/drop membership
	ioctls take an interface and that the client level must take
	care of routing a multicast packet to the appropriate interface
	and listening for multicast packets on appropriate interfaces.
	It seems to me this is pushing too much up to the client.  (It's
	really the first time that network interfaces, as opposed to IP
	addresses, are visible to clients.)  Was this a deliberate
	design decision or an attempt to get around limits in the kernel?

It was a deliberate design decision.  The model I have in mind is
that a host transmits an IP multicast packet as a local multicast on
a single network and multicast routers deliver it to destination members
on other networks.  If a multihomed host transmits copies of the same
multicast packet via multiple interfaces, it would normally result in
delivery of unwanted duplicates to the membership -- the routers cannot
tell that the copies originated at the same host.  Also, joining a group
on more than one interface would, in general, result in duplicate
reception.

An exception to the above behavior occurs when a host uses a very
small IP time-to-live value to limit the scope of the multicast,
explicitly preventing delivery to all members of the destination group.
In this case, the multihomed host must decide which network to use as
the origin of the scope-bounded multicast.

Of course, IP multicast packets originating within a host that is
acting as a multicast router will be transmitted via multiple
interfaces, if necessary to reach destination group members.  However,
even in this case I would keep the notion of the packet being sent to
one network and "forwarded" to the other networks, because:
(1) it allows code developed for the non-multicast-routing host to
work the same way on the multicast-routing host, and (2) it allows an
application on a multicast router to direct a TTL=1 multicast to
a single, specific network, which is important when the multicast
information is network-relative, as in routing protocols.

Another way to look at this is to consider the multicasts to be
transmitted along a tree whose nodes are networks and arcs are
routers.  There is a single root network for every multicast
transmission.  An alternate model would be to view the hosts and
routers as the nodes, and the networks as the arcs, but in that
model I don't know how to accomodate non-routing, multihomed hosts
and still avoid duplicates.  Also, I believe my "network-centric"
(as opposed to host-centric) view is consistent with IP unicast
routing.  Non-gateway, multhomed hosts have similar problems with
unicast routing: they must choose, without any help from a routing
protocol, which interface to use when sending to a non-neighboring
destination.

I don't agree that this is the first time that interfaces become visible
to clients.  If you look at the rwhod program (without my modifications),
you'll see that it queries the kernel for a list of interfaces in order
to determine an appropriate IP broadcast address for each attached
network.  On transmission, it is basically encoding the choice of
interface as part of the destination broadcast address, an option that
is not available for network-independent IP multicast addresses.

To conclude, I think that use of a single, default interface for multicast
transmission and group membership is the right approach for multicasts
that are intended to reach all members.  For multicasts intended for
"nearby" members only, an application running on a multihomed host has
to decide which interface those members should be near to.

Steve