multicast TTL settings

[Bill Nickless]

At 01:45 PM 6/28/99 -0500, Robert Olson wrote:
>What if the required TTL turns out to be something like 127 that is
>equivalent to full Mbone span? As I understand things, the admin scoping is
>the new preferred mechanism for doing things like this...  or is the state
>of mrouting now such that one can push out several Mbps of multicast
>traffic on a relatively high ttl and not get lots of people pissed off.
>
>(I guess this is something we may learn empirically soon :-)

I would argue that sites and/or networks should use lower TTL settings for
MBONE links that have better connectivity.  To require 127 to just get off
site seems a relatively unsophisticated policy.  As I've mentioned,
Argonne's get-offsite-to-well-connected-peers-like-vBNS-and-ESNet TTL is 32.

Recall that the problem with large bandwidth multicast flows is that the
traditional DVMRP-based routing does flood-first-then-prune.  Newer
multicast-BGP in cooperation with PIM sparse-dense mode is considerably
more sophisticated and forgiving.  The Introduction to RFC 2365 discusses
the problems with DVMRP clearly.

Here are a couple of quotations from RFC 2365 (which defines administrative
scoping):

   In order to support administratively scoped IP multicast, a router 
   should support the configuration of per-interface scoped IP multicast 
   boundaries. Such a router, called a boundary router, does not forward 
   packets matching an interface's boundary definition in either direction
   (the bi-directional check prevents problems with multi-access 
   networks). In addition, a boundary router always prunes the boundary 
   for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode
   groups [PIMSM] in the administratively scoped range.

   [...]

   An administratively scoped IP multicast region is defined to be a
   topological region in which there are one or more boundary routers 
   with common boundary definitions. Such a router is said to be a 
   boundary for scoped addresses in the range defined in its 
   configuration.

Note that the very definition of administrative scope configuration is at
the router *interface* level.  To define an administrative scope for
access-grid activities would require all networks carrying access-grid
traffic to classify their router interfaces either ACCESS_GRID_OK and
NOT_ACCESS_GRID_OK and assign administrative scope appropriately.
Implementing such a scope would require unprecedented cooperation across
all possible participating networks.  EVERY multicast router interface at
the boundary of EVERY network participating in AG activities would have to
be evaluated and configured.  This flies in the face of the effort to make
multicast routing ubiquitous everywhere.

Administrative scope makes sense where the boundaries of the multicast
session traffic match the boundaries of a network.  In contrast, Access
Grid traffic uses many networks across many organizations.  I believe that
it is, by definition, a high-bandwidth full MBONE application.  If problems
with bandwidth overutilization are discovered, these should be treated as
drivers for MBONE re-engineering (especially site connection TTL policy
changes) as appropriate.
--
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at mcs.anl.gov