[ih] IPv8...

[Brian E Carpenter]

There was also a possible niche for small-group wide area multicast.
But that never caught on despite considerable effort by Rick Boivie
at IBM.

https://datatracker.ietf.org/doc/html/draft-boivie-sgm-02

Regards/Ngā mihi
    Brian Carpenter

On 22-Apr-26 08:04, Jack Haverty via Internet-history 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.
>>>
>>>
>>
> 
>