Re: Comments on <draft-ietf-udlr-multicast-issues-00.txt>

I am happy to co-author something along these lines with more specific
text, if this seems useful... let me know.

Gorry Fairhurst

----

Routing & group membership reporting

Dense-mode routing protocols such as DVMRP and PIM-DM, are not
well suited for use over subnetworks with a large round trip delay.
Such protocols rely on flooding all multicast packet until they
receive an explicit "prune" message. Three reasons why
this is not good in this context:

(i) If the subnetwork offers a broadband service, then there may be
a need to connect to the Internet Multicast Backbone. This
backbone carries a large number of groups. Each
group will (from time to time) be flooded - consuming local
resource (capacity, state) - and also network resource from
the upstream networks which source the data. This is a classic
scaling problem appropriate to any service multicast network.

(ii) If the subnetwork has asymmetric loss (or capacity) then the
loss of a routing "prune" message will prevent the group being
pruned. This leads to continued forwarding of a group which
is not required (i.e., consumes forward capacity for multicast
flooding, and return capacity for routing "prune"messages).

(iii) If the subnetwork round trip transit delay is appreciable,
then this delays the reception of prunes.  This also increases
the load (i.e., may consume much more forward capacity than
for a low latency subnetwork).

The use of Sparse-Mode (e.g., PIM-SM) is therefore desirable
for links which have limited capacity and/or exhibit loss and/or
a high round trip transit delay. Use of PIM-SM with UDLR has 
also been suggested as desirable.

There is on-going work to develop appropriate configuration policy 
for PIM-SM in hybrid (terrestrial/Satellite) networks concerning 
the choice for Rendezvous Points (RP) and switching from the 
RP-routed tree to shortest path tree. There are also issues in 
scaling to a large number of routing peers.

IGMPv2 also suffers scaling issues similar to, but different from,
those encountered with dense-mode routing protocols:

(i) A large subnetwork round trip transit delay increases reduces the
effectiveness of the feedback suppression technique.  The number
of membership reports received per membership query is increased when there
are many members of the same set of groups.

(ii) Too small a query interval, may result in multicast routers assuming
that there there are no responders, when membership report messages are
actually still in flight over the subnetwork. This case could
lead to interruption of the multicast service.

(iii) A large query interval may lead to a significant delay in removing
unnecessary  multicast traffic.

IGMPv3 does not use a suppression technique to reduce the number of
membership reports. The volume of IGMPv3 traffic is not impacted by
the subnetwork round-trip transit delay. A small query interval may lead to
interruption of the service, but the "leave processing" in IGMPv3 is not
normally impacted by query interval.

----

Applications

Multicast applications such as caching, streaming, and reliable transfer are
not specific to satellite -  but there may be design considerations such as
placement of caches (and other multicast agents), the effect of delay, the
effect of subnetwork outages, and potential interactions with
bandwidth-on-demand techniques. These may influence the design and
configuration of systems intending to use broadband satellite networks.

There are implications on using long delay subnetworks, on the control
functions within protocols.  For example,  some variants of
TCP Friendly Rate Control.  Some proposed implementations utilise group
round trip delay measurements. The presence of a receiver over a long delay
subnetwork may adversely impact the throughput obtained by all members of
the group.

There is also a question of scale. Most current multicast applications in
use on the Internet address only modest (less than a hundred) receivers,
future deployment will requiring scaling to very much larger groups.
satellite subnetworks may be the first place to see this need.

I don't think we should be standardising protocols in this area - but we
may usefully identify guidelines and requirements!!!