Subject: Re: mrouted 3.8 - more aggressive pruning? and why all senders in kernel?

From: Bill Fenner <[email-masked]>
Date: Mon, 17 Mar 1997 11:58:37 PST

Apologies for the empty message; mh is apparently bad at noticing that
the disk is full.

Brad Parker <[email-masked]> wrote:
>I also suspect that some of the prune messages where being
>dropped by the router upstream...

You can "kill -USR2 `cat /var/run/mrouted.pid`" and mrouted will
create /var/tmp/mrouted.cache, which you can then examine to see
what prunes have been sent (a "P" after the incoming interface).
You can compare that with the upstream router's notion of what
prunes have been received.

>I made a small change in prune.c/add_table_entry to refuse to add
>kernel cache entries if there where no subscribers to the group.
>I found that this cleaned up my "problem" completely.

This will work only when the majority of the traffic is arriving
via a tunnel.  The kernel mechanism that cleans up cache entries
is really only meant to handle dropped messages.

>Now when unsubscribed and unpruned sources send messages
>they are pruned quickly.

This is what an unmodified mrouted 3.8 is supposed to do (and does
on my Sun at home at the end of an ISDN line).

>The only problem I can see with this is that it's not rate limited,
>and probably should be (this would be easy to add).  (I suspect sending
>this email will inform me of others, however :-)

The reason that simply failing to install the cache entries is bad is
that on a multi-access interface, you may continue to receive traffic
despite having sent a prune (e.g. if there is a group member on the
incoming interface, or if there is another multicast router that
desires to receive the traffic).  In this situation, your solution
would thrash the forwarding cache.

mrouted 3.9 (currently in alpha-test) keeps a small kernel cache as a
pleasant side-effect of the prune retransmission algorithm; when prunes
work, cache entries get deleted after about 3 seconds.  It also
exponentially backs off the prune retransmissions and jitters the
timers to avoid synchronization.  Prune retransmission also helps
"heal" upstream routers which forget prune state.

To summarize, mrouted 3.8:
a) is meant to work without your change, and does work in a similar
  configuration under SunOS
b) installs cache entries for all traffic because it expects that it
  is connected to multi-access networks [tunnels are a special case]

I'd be happy to have you alpha-test mrouted 3.9 to see if it solves the
same problems as your modification does.

  Bill