[ih] IPv8...

[John Day]

I believe the first work on multicast was Yogen Dalal’a Phd thesis in the 1970s, where he first worked out a distributed spanning tree algorithm.

Take care,
John Day


> On Apr 21, 2026, at 15:33, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Oh now  i have to look at Lorenzo's paper.  He gave me an acknowledgement. It was a long tine ago.  I think Jim Mathis was heading the Metanet project so he probably has a better chance of remembering more about the tasks.
> Zaw-sing Su is also acknowledged.  You might be interested in his paper on naming/addressing: "Identification in Computer Networks"
> https://dl.acm.org/doi/epdf/10.1145/964661.800901
> barbara
> 
>    On Tuesday, April 21, 2026 at 10:21:55 AM PDT, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:  
> 
>  Are you  familiar with the work of Lorenzo Aguilar (SRI) ?  He did work on multicast in the Internet that might predate Steve Deering's contributions. It looks like he was at Ohio State when he started thinking about multicast (1982 thesis?).  On the Metanet project at SRI, he did additional multicast work. I found one paper he published on this work:  "Datagram Routing for Internet Multicast" (1984)
> https://dl.acm.org/doi/epdf/10.1145/639624.802060
> I have mentioned the Metanet Project before. This is the Navy project that got cancelled early. I worked on a gateway in Ada (when Ada was hot).  Another piece was supporting communication during EMCON.
> Kinda busy right now so haven't  had a chance to read Lorenzo's paper. I just know he had a task. I can't quickly find a copy of his thesis(?).
> barbara
>     On Tuesday, April 21, 2026 at 08:47:06 AM PDT, John Day via Internet-history <internet-history at elists.isoc.org> wrote:  
> 
> Thanks for the correction.
> 
> Not terribly precise, but I wouldn’t expect that.
> I presume there then has to be some method for notifying stations and links that they should be willing? Seems to be an unnecessary complication. In most multicast proposals/implementations I have seen, an application requests to join a service that uses multicast, which would seem to make ‘willingness’ moot. 
> 
> (Applications shouldn’t have to sp Secifically request multicast. The provider determines whether to simply send n copies or use multicast. It is the provide that benefits, not the application.)
> 
> Thanks again,
> John
> 
>> On Apr 21, 2026, at 11:31, Craig Partridge <craig at tereschau.net> wrote:
>> 
>> 
>> 
>> On Tue, Apr 21, 2026 at 8:58 AM John Day via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>>> Let me try to provide some other definitions of multicast and anycast that will either help or confuse things.
>>> 
>>> First the definition of multicast in the Internet is patterned after multicast in Ethernet. That definition assumes that all stations see all packets, which implies flooding. This is what happens in Ethernet so it is quite natural and works well. However, it isn’t so useful for general networks, where one would like to avoid flooding. Perhaps a better more abstract definition would be:
>>> (I hesitate to call it a multicast *address* even though it is taken from the IP address space because an address is location-dependent and route-independent. That doesn’t really apply to multicast in general.)
>> 
>> You clearly don't understand Deering's contribution to multicast.  He took the semantics of Ethernet multicast and generalized it to an Internet such that "all stations see all packets" but rather only those stations and links willing to receive/carry the multicast address (or, if you wish, a group of multicast addresses of which the target multicast address is one) see the packet.
>> 
>> This simplification also applies to anycast in an Internet context.
>> 
>> Craig
>> 
>> --
>> *****
>> Craig Partridge's email account for professional society activities and mailing lists.
> 
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history