Subject: Discovery of pruning problem

From: Stephen Casner <[email-masked]>
Date: Thu, 30 Jan 1997 23:13:53 -0800 (PST)

[Any discussion should be on MBoneD list, but this msg bcc'd to MBone
for wider notification.]

Perhaps many of you already knew about this problem, but working with
Manoj Leelanivas from cisco I just learned that multicast TTL scoping
prevents pruning from working.  That is, any point where the TTL
expires or does not exceed a threshold will be a non-pruning sink for
that traffic whether or not there are any group members downstream.

In case it's not clear, this isn't just an implementation problem.
At first glance, one might think that when a packet is discarded
because the TTL expires or is insufficient, a prune could be sent.
After all, that is specified as part of the required action in the
case of a packet running into an admin scope boundary.  However, for
the TTL scope, the next packet to the same group might have a larger
TTL, and if the prune had been sent, that packet would not get
through.  To make this work, prune state would have to have a TTL
associated, and that's not likely to be added.

As Bill Fenner put it, this is just another example of how TTL
scoping is inadequate and why we should use admin scoped addresses
instead.  This point should probably be included in Maufer &
Semeria's document, and perhaps mentioned in the admin scoping I-D as
well.  I suspect that many people are not aware of this problem, and
I believe it should be mentioned in configuration manuals, etc.

Note that this is not a problem when using the TTL for expanding-ring
search, which I guess is the only function the TTL is really supposed
to have (for multicast).

The way that we've primarily used TTL scoping in the MBone is to keep
traffic inside the boundaries of an organization.  What this problem
means is that all internal traffic will be drawn to the boundary
router even if that is far from the source and any receivers.  Our
recommendation should be that all sessions intended for less than
global scope should use admin scoped addresses.  It is still fine to
apply a TTL scope as well and to put the TTL threshold at the same
place as the admin scope boundary as a backup just in case the admin
scope should be accidentally removed.  You just don't want to let any
packets get stopped due to insufficient TTL inside the domain.

For the November 1992 IETF, before pruning was implemented, we also
defined some TTL thresholds above 127 to allow different levels of
bandwidth limitation (allowing audio but not video, or only one audio
channel but not both, etc.).  If there are any links still out there
with TTL thresholds of 128 or greater, those will act like
non-pruning sinks for all the sessions which have the typical global
TTL scope of 127 applied.  We might not notice this problem until the
more significant goal of eliminating all non-pruning routers is
achieved, but it will come up.  Some while back, Tom Maufer added
those higher thresholds to the table in their document at my
suggestion, but perhaps those should be eliminated in light of this
pruning problem.

I learned of this TTL scope problem during an exploration of pruning
within Precept's network, both to see why we had excess traffic
coming in from the MBone and internal traffic going to subnets where
there were no listeners.  I found several things wrong with our
configuration.  As part of the exercise, I also learned that cisco
routers ignore DVMRP prune messages (e.g., from mrouted) that are
received over a multi-access interface (e.g., Ethernet), even when
"ip dvmrp unicast-routing" is configured so the cisco will exchange
DVMRP routing.  So those ciscos are going to forward all traffic for
which the mrouted is downstream.  One way to avoid this is to let
ciscos and mrouteds interface only through tunnels.
							-- Steve

---

From: Liming Wei <[email-masked]>
Date: Fri, 31 Jan 1997 00:41:23 -0800 (PST)

[Kept bcc'ing the mbone list.]

> that traffic whether or not there are any group members downstream.

Steve, I am glad that you raised the admin scoped boundary issue.
It has been available for quite a while (in cisco's router implementation,
mrouted and its derived implementations), but its deploymement and
usage have been at a negligible level.

I think this is mostly due to two reasons:

 1) There lacks a good way to form a hierarchy of admin-scoped boundaries,
    especially when the sub-domains are administered independently,
    and the hierarchy grows both in "height" and "width".
    On the other hand, the ttl mechanism provides a convenient way
    to describe the hierarchical nature of different multicast scopes,
    e.g. 16:local, 32:site, 64:ISP, etc. The departmental netadmin
    does not need to agree with the higher level netadmin on what
    addresses to use.  But with administratively sccoped boundary
    addresses, netadmins at different level and the address allocation
    programs need to agree on which sub-range of 239/4 reach what
    level of the hierarchy.

    As a matter of fact, there can be a lot of problems if different
    people carve up the 239/4 range differently.
    One obvious example is when two scoped regions want to
    "merge" into one multicast scoped region (but still managed
    by different netadmin), the merge can be totally non-workable
    without a complete reconfiguration of the border routers,
    and the address allocation programs.

 2) Currently SDR assigns all addresses from the 224.2.0.0/16 pool.
    The only ways to specify a scope of a group is via ttl.
    There is no sensible way to put up admin-scoped boundaries
    for these addresses.

So I think it is high time to put some well-known, extensible,
hierachical structures into the 239.0.0.0/4 range.
 
-Liming