[ih] IPv8...

[Jack Haverty]

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.
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20260421/5c592850/attachment-0001.asc>