[ih] IPv8...

[Karl Auerbach]

On 4/21/26 1:04 PM, Jack Haverty via Internet-history wrote:
>
> 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?) 

When we formed Precept Software in 1995 we (Steve Casner, Dino F. 
[Cisco], Judy Estrin, Chia-Chee Kuan, myself, and several others) worked 
mightily to get classic IP multicast to work for the carriage of audio 
and video streams.

It kinda worked OK in small environments under a single administration.  
DVMRP (flood-and-prune) routing worked OK until we powered up a little 
Cisco 2514 in a new corner of our company net.  It quite nicely became a 
destination for the entire MBONE, but because we hand not configured its 
unicast numbers yet the poor little box had no way to say "prune" - so 
our mere T-1 feed from the net became saturated and we effectively went 
offline.

PIM sparse mode worked better.  Then we were acquired by Cisco. They 
used IP multicast for some of their phone stuff, and they had configured 
PIM sparse mode so that all IP multicast transited to the far distant 
end of the Cisco net and then came back - an extremely poor routing 
solution that surprised Cisco's internet infrastructure folks who were 
expecting light loads of IP multicast for the phones and whose 
inter-building links were clobbered with our group's continuous and 
simultaneous playout of several movies (mostly Blade Runner and Lion 
King because we had Laser Discs for those.)  Also, because the IP phones 
had limited hardware filtering of Ethernet frames containing IP 
multicast, we ended up overloading and crashing virtually every IP phone 
at Cisco.

Along the way we ran through the various generations of IGMP.  We 
received many a curse from Cisco's infrastructure group because IGMP did 
not shut-off streams immediately after a member left the multicast 
group.  Rather there was often a lingering flow, especially if the IGMP 
Leave message were lost or IGMP was mis-implemented by a client (which 
was rather frequent - we got Microsoft to retract a Windows update 
because they had really messed up their IGMP code.)

Fred Baker and I worked on RSVP (I did the client side, Fred did the 
router side) to help announce and manage the loads, but it turned out 
that RSVP, in its grand design, was kind of like moving from Newtonian 
astrophysics to General Relativity in a single step.

After we had become greatly deformed from banging our heads against IP 
multicast routing management - and its myriad of failure cases - Dave 
Cheriton and one of his students (all I remember is that one of his 
initials was "H") came by with what we felt was a smart and 
revolutionary idea - that perhaps IP multicast need not be all-members 
but, rather, there could be a single source multicasting to its 
members.  This made things so much easier and cleaner.  But by then the 
fate of IP multicast was already beginning to be sealed by its 
reputation as a nightmare to manage.

There is a lot of useful stuff that single source multicast could have done.

I ended up trying to work around the fact that IP multicast did not seem 
to have much of a future by recognizing that for our need - 
dissemination of entertainment grade audio/video - that we did not have 
to have closely synchronized playout by the clients.  So I moved the 
idea of "multicast" up to the application layer - my own code - where I 
could administratively form distribution trees to get content to 
audio/video servers, using some ideas taken from multicast file transfer 
proposals (such as repair of loss by doing expanding ring searches to 
fetch the missing data from other receivers nearby) and leaving the 
ultimate distribution near the edges to either traditional 
server-to-client point-to-point connections or via constrained/local IP 
multicast realms.  (I basically ended up with a service that appeared to 
users much like what became today's network based [non-red-envelop] 
Netflix at about the same time a couple of my neighbors here in Santa 
Cruz invented the red-envelope Netflix.  I accidentally doomed the 
project because, driven by my live-theatre background, I had begun to 
develop methods of doing dynamic content replacement and fourth-wall 
breaking image/voice/pacing morphing of content to different viewers and 
reacting to events in the viewer space. These are things that would be 
very valuable alternatives to today's 
advertising-interrupting-everything media world. But my work was noticed 
first not by my intended customer base but by the porn industry.)

         --karl--