[ih] IPv8...

[John Day]

Good stuff. Thanks.
As I said, in reading papers on this there is a wide variety of solutions, mostly application specific.
John

> On Apr 21, 2026, at 18:02, Karl Auerbach <karl at iwl.com> wrote:
> 
> 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--
>