[ih] IPv8...

Tue Apr 21 13:38:48 PDT 2026

I would not include applications that basically sent the same message to n-members of a ’session’. An application that used multicast to accomplish the same thing is a different matter. The two main categories of multicast, I would think, would be:
1) single-source to n-members,
2) n-sources to n-members, e.g. core-based trees

The thing about this is there are many parameters: static or dynamic population, Known or unknown members, etc.  Somewhere I have a list of more.

I would question the inclusion of the ever-popular ‘reliable multicast’. They all seem to take very application-specific solutions to ack-implosion. There doesn’t seem to be a really general solution and the ’solutions’ don’t really seem to be part of multicast.

Take care,
John Day

> On Apr 21, 2026, at 16:04, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> I'd argue that there are 3 categories:
> 
> 1) IP-level multicast (perhaps no longer in use or supported by the IP infrastructure?  But if so, was it deemed too difficult, or just a case of lost interest?)
> 2) app-level bidirectional multicast (teleconferencing, perhaps technology used is unique to each application and thus not interoperable?)
> 3) uni-directional multicast (streaming video to thousands of viewers, seems to work with occasional issues, at least at current levels of usage)
> 
> With the rapid rise of Streaming as a replacement for broadcast and cable TV, and the amount of data involved in transmission of movies and TV shows, I wouldn't be surprised if the Internet traffic has been growing increasingly to be eventually dominated by category 3.  But I have no idea if however that works today uses any kind of "multicast" techniques, either within the IP infrastructure or apps.
> 
> I remember many of us thought, back in the 1980s, that the current mechanisms of the IP level had lots of limitations, but that everything would mostly work as long as the physical topology expanded faster than the users' traffic demand.  When demand approached the limits of available supply, bad things should be expected to happen, so techniques such as IP multicast were needed, and that capability would be evolved into the Internet machinery once the research results coalesced into a standard.
> 
> Perhaps there's just so much capacity now in the Internet, and will be in the future, that such concerns don't matter any more?  (I'm not convinced....)
> 
> Back in the ARPANET era, there were lots of analytical studies of the mechanisms of packet networks.  Lots of measurements were also taken, to compare real-world behavior to the predictions of analytical models (such as Kleinrock's work at UCLA, and later BBN's work to monitor the ARPANET as it grew and use the data gathered to modify the internal mechanisms based on operational behavior.
> 
> Have such theoretical analyses and operational experience ever been applied to The Internet?    For example, the internal mechanisms in the ARPANET based routing decisions on measurements of transit time for packets to traverse the ARPANET.   For pragmatic reasons, that was not feasible in the early Internet, and routing decisions were based on "hops" instead of time.  Maybe that's still true?
> 
> Was the Internet ever analyzed mathematically as the ARPANET was? Or were (are?) measurements of operational behavior used (or even collected?) in some way to influence technical evolution? Personally I haven't seen any discussions of such things but I also haven't been looking.   But I think it's an important aspect of Internet History.
> 
> /Jack
> 
> On 4/21/26 11:49, Guy Almes wrote:
>>   If I can make a brief and modest suggestion, it's that we can distinguish two versions of Jack's question below:
>> <> uses of multicast at the IP (level 3) level, vs.
>> <> uses of multicast at the application level.
>> 
>>   One of the problems with IP-layer multicast in the early 1990s is that some very smart people built the MBone and Vic and Vat, etc., and made it work.  For several years, there seemed to be kind of fixed idea that to do (e.g.) audio/video-conferencing, you had to implement IP-layer multicast.
>>   During my two years at NSF, I participated in many video-conferences based on such tools.  And there was always a period of several minutes in which very smart people had to check to make sure it was all working etc. before the "real" conference started.
>>   Fast forward to 2020, and the Covid-afflicted world found Zoom etc. available and very usable.
>>   It was still multicast, but not at the IP layer.  So much less wizardry!
>> 
>>   Other examples of non-IP-layer multicast include the whole content distribution network infrastructure.
>> 
>>   Oh, and for completeness, I should have noted the obvious continued use of layer-2 multicast with ARP etc. that still works.
>> 
>>   So I support conversation on Jack's question, distinguishing IP-layer vs (mainly) application-layer multicast.
>>   Finally, I'm not aware of anything I'd call Transport-layer multicast, but one can sort of imagine such a thing.
>>     -- Guy
>> 
>> On 4/21/26 12:20 PM, Jack Haverty via Internet-history wrote:
>>> Can anyone summarize the history of the *use* of "multicast" in The
>>> Internet?  I know the various protocols and such are probably well
>>> described in publications such as RFCs and research reports, but I'm
>>> wondering about the historical timeline of the actual implementation and
>>> use of multicast in the Internet we have all used for years or decades now.
>>> 
>>> For example, I remember the "Mbone" which was used for lots of
>>> experimentation in the 1980s.     IIRC, Mbone had some kind of support
>>> for multicast, and required that routers along the path you were using
>>> through the Internet had to have implemented the protocols and
>>> algorithms for the multicast mechanisms of the time. This affected
>>> activities such as the various projects experimenting with interactive
>>> voice over the Internet in the 1980s.   The Mbone was in effect a subset
>>> of The Internet.
>>> 
>>> Almost 50 years later, it's pretty common for people to be using the
>>> Internet in ways that would seem to benefit from use of some kind of
>>> modern "multicast" scheme.  A typical example would be teleconferencing,
>>> using Zoom, Meet, Facetime, or any of the other similar systems.   I use
>>> such things frequently; you probably do too.
>>> 
>>> None of those systems seem to be "interoperable", i.e., able to hold
>>> conferences where different participants use different companies'
>>> technology to participate in a single conference.  Do they actually use
>>> the standards for multicast defined in RFCs?
>>> 
>>> Does the "Mbone" still exist as a subset of The Internet?  Did it grow
>>> and evolve over time to become part of today's ubiquitous Internet
>>> infrastructure or did it just disappear?
>>> 
>>> I replaced my home routers last year.  The old routers, bought a few
>>> years ago, still work but are sitting on a shelf, and I just got a
>>> notice from the manufacturer that they are now considered obsolete.  But
>>> I don't remember that either the new ones or old ones promoted
>>> themselves as "Supports Multicast!!" or anything like that.  I also
>>> don't remember any of the teleconferencing schemes saying anything like
>>> "Requires Multicast Routers!!".
>>> 
>>> So it's hard to tell if any multicast technology is actually needed, or
>>> even present, or used at all in The Internet today.
>>> 
>>> Perhaps multicast mechanisms are just no longer needed?  With the planet
>>> being increasingly woven into a spider's nightmare blanket of fiber, and
>>> also being encapsulated by tens of thousands of satellites weaving
>>> complex webs of radio and laser beams, does efficiency matter as much as
>>> we worried about in the early days of The Internet?
>>> 
>>> What's the history of the *use* of multicast as the Internet has grown
>>> and changed over time?
>>> 
>>> /Jack Haverty
>>> 
>>> On 4/21/26 08:46, John Day via Internet-history 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 specifically 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