[ih] IPv8...

[Karl Auerbach]

On 4/21/26 1:38 PM, John Day via Internet-history wrote:

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

Reliable multicast came in two flavors - reliable *streams* (in which 
the subscriber got a reliable stream between the time the subscriber 
joined and the time the subscriber left) and reliable *file transfer* 
(of blocks of data with a distinct beginning and end.)  These were quite 
different things.  And there were several ideas and implementations for 
each.  Reliable file transfer also got into messy issues such as "what 
if a subscriber joins late?"

Many of these avoided acks but rather used TTL based ring expanding 
searches to find other subscribers from whom lost data could be obtained 
- that may raise thoughts about Bittorrent.

Another method was redundancy - the most common form was RAT, Redundant 
Audio Technology - in which the audio muliticast stream followed the 
full quality sound packets with reduced quality sound packets (with a 
delay between the high quality and low quality packets in hopes that the 
loss was transitory).  Human ears don't like sound gaps but they seem 
well tuned to dealing with short bursts of degraded quality sound.

Steve Casner and I did a fairly full implementation of RTP/RTCP 
including its large multicast group support.  Because RTCP had receivers 
reporting on the quality of their reception it was possible that in 
large groups that there would be implosions.  So RTCP had various 
backoff algorithms (which if I remember were not hard to implement but 
rather hard to test.)

It being the mid-to-late 1990's we gave almost no thought to security.

         --karl--