No subject was specified.

I've drafted a numebr of "draft" sections for the general document
being produced by this group. While others are working on their
contributions, I thouyght I would try to get a feel for the sense
of the list on the characteristics of UDLR links that may impact
multicast performance. I'm not looking for the exact impacts at
this stage, more a sense of the properties that need to be 
considered for the different posisble UDLR links...

Any thoughts?

--- please send replies to me (I'll cummarise) or this list.

Gorry


----


Characteristics of UDLR networks

UDLR subnetworks present characteristics which differ significantly from
those experienced in the general Internet. These characteristics lead to
specific problems and raise specific issues that need to be addressed to
deploy an IP multicast service.  This section identifies specific
characteristics that impact multicast performance resulting from the
asymmetry and the types of network over which the UDLR is commonly
implemented.  These are:

1.1.1 Asymmetric routing paths
Unidirectional links give rise to differing forward (feed) and return
(tunnel) paths. Multicast routing protocols that use the "reverse
shortest path tree" towards the source as a part of their forwarding
decision (e.g. DVMRP, PIM-SM [DRAFT-PIM-SM-NEW], PIM-DM) will not work
correctly over asymmetric routing paths. Solutions include the use of
UDLR [RFC 3077] and the use incongruent MBGP routing. 

1.1.2 Asymmetric multicast capability
Asymmetric multicast capability is not a fundamental feature of UDLR. 
In some UDLR networks both forward (feed) and return paths may support
native IP multicast.  In other UDLR networks, a case may arise where the
forward link supports native multicast, whereas return link may supports
only unicast. UDLR routing allows a non-broadcast/multicast link to be
used for the return path by employing a tunnel in the return direction [RFC2784].

1.1.3 Forward link capacity
Since many UDLR networks employ wireless technology for the forward
(feed) link (e.g., [EN00]), there may be an appreciable cost for
forwarding traffic on the feed link. This leads to a desire to prevent
forwarding unnecessary multicast traffic, this implies the need to
control which groups are forwarded. However, other factors, (e.g.,
asymmetric links, and asymmetric loss environment), may suggest a desire
to minimise the volume and frequency of control messages in the return direction.

1.1.3 Asymmetric link capacity
The capacity of the forward (feed) and return (tunnel) paths may differ
significantly (e.g., forward link using DVB-S [EN00], return using a GRE
tunnel over a dial-up modem or ISDN interface for the return path). The
high normalised bandwidth ratio can lead to a performance bottleneck, in
addition the “cost” of setting up and maintaining capacity in the
reverse direction may be significantly greater than in the forward
direction [DRAFT-PILC-ASYM].  Although a class of multicast applications
do not require a return path for their transport protocol (e.g.
unidirectional transmission of multimedia using RTP
[DRAFT-AVT-RTP-NEW]), a path may still be required for other supporting
protocols (e.g. DNS, IGMP , Multicast Routing).  The cost of
establishing and maintaining a return path for these applications may be
appreciable, especially considering its minimal use.  

1.1.4 Asymmetric loss environment 
UDLR does not by itself introduce an imbalance in the packet loss rate
between the transmit and receive paths, however different link
technologies are often used to implement the forward (feed) and return
(tunnel) links of UDLR networks. In some important cases this can lead
to a significantly higher probability of packet loss in the return
direction [DRAFT-PILC-ASYM].

1.1.5 Flat networks 
The link technologies that are often used to implement the  UDLR  feed
link may support a multicast/broadcast capability that permits a very
large number of directly connected downstream receivers. For example, a
single satellite down-link may support 1tens of thousands of UDLR
Receivers. The numbers of Receivers connected via the same physical link
may be much larger than found in other common LAN technologies, (e.g.
Ethernet).  Current routing protocols, and some multicast application
protocols do not scale to arbitrary large numbers of participants. 

1.1.6 Subnetwork round trip delay 
UDLR does not by itself introduce an appreciable subnetwork round trip (RTT)
delay, however many practical UDLR networks are built using links that
may introduce significant path delay (e.g. satellite links). Since the
subnetwork round trip delay impacts the performance of the protocols
that support the multicast service, the impact of this delay needs to be considered.