As per Relevance of the word mechanism, we have this rfc below:
Network Working Group M.
Request for Comments: 2887 S.
Category: Informational
B.
R.
L.
M.
Digital Fountain, Inc
August 2000
The Reliable Multicast Design Space for Bulk Data
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
The design space for reliable multicast is rich, with many
solutions having been devised. However, application
serve to constrain this design space to a relatively small
space. This document provides an overview of the design space
the ways in which application constraints affect possible solutions
1.
The term "general purpose reliable multicast protocol" is
of an oxymoron. Different applications have different
of a reliable multicast protocol, and these requirements
the design space in ways that two applications with
requirements often cannot share a single solution. There are
many successful reliable multicast protocol designs that serve
special purpose requirements well
In this document we attempt to review the design space for
multicast protocols intended for bulk data transfer. The term
data transfer should be taken as having broad meaning - the
limitations are that the data stream is continuous and long lived -
Handley, et al. Informational [Page 1]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
constraints necessary for the forms of congestion control
currently understand. The purpose of this review is to
together an overview of the field and to make explicit
constraints imposed by particular mechanisms. The aim is to
guidance to the standardization process for protocols and
building blocks. In doing this, we cluster potential solutions
a number of loose categories - real protocols may be composed
mechanisms from more than one of these clusters
The main constraint on solutions is imposed by the need to scale
large receiver sets. For small receiver sets the design space
much less restricted
2. Application
Application requirements for reliable multicast (RM) are as broad
varied as the applications themselves. However, there are a set
requirements that significantly affect the design of an RM protocol
A brief list includes
o Does the application need to know that everyone received the data
o Does the application need to constrain differences
receivers
o Does the application need to scale to large numbers of receivers
o Does the application need to be totally reliable
o Does the application need ordered data
o Does the application need to provide low-delay delivery
o Does the application need to provide time-bounded delivery
o Does the application need many interacting senders
o Is the application data flow intermittent
o Does the application need to work in the public Internet
o Does the application need to work without a return path (e.g
satellite)?
o Does the application need to provide secure delivery
Handley, et al. Informational [Page 2]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
In the context of standardizing bulk data transfer protocols, we
rule out applications with multiple interacting senders
intermittent data flows. It is not that these applications
unimportant, but that we do not yet have effective congestion
for such applications
2.1. Did everyone receive the data
In many applications a logically defined unit or units of data is
be delivered to multiple clients, e.g., a file or a set of files,
software package, a stock quote or package of stock quotes, an
notification, a set of slides, a frame or block from a video.
application data unit (ADU) is defined to be a logically
unit of data that is useful to the application. In some cases,
application data unit may be short enough to fit into a single
(e.g., an event notification or a stock quote), whereas in
cases an application data unit may be much longer than a
(e.g., a software package).
A protocol may optionally provide delivery confirmation to
reliable delivery, i.e., a mechanism for receivers to inform
sender when data has been delivered. There are two types
confirmation, at the application data unit level and at the
level. Application data unit confirmation is useful at
application level, e.g., to inform the application about
progress and to decide when to stop sending packets about
particular application data unit. Packet confirmation is useful
the transport level, e.g., to inform the transport level when it
release buffer space being used for storing packets for
delivery has been confirmed
Some applications have a strong requirement for confirmation that
the receivers got an ADU, or if not, to be informed of which
receivers failed to receive the entire ADU. Examples
applications where receivers pay for data, and reliable file-
replication. Other applications do not have such a requirement.
example is the distribution of free software
If the application does need to know that every receiver got the ADU
then a positive acknowledgment must be received from every receiver
although it may be possible to aggregate these acknowledgments.
the application needs to know precisely which receivers failed to
the ADU, additional constraints are placed on
aggregation
It should be noted that different mechanisms can be used for ADU
level confirmation and packet-level confirmation in the
application. For example, an ADU-level confirmation mechanism
Handley, et al. Informational [Page 3]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
positive acknowledgments may sit on top of a packet-level NACK
FEC-based transport. Typically this only makes sense when ADUs
significantly larger than a single packet
2.2. Constraining
Some applications need to constrain differences between receivers
that the data reception characteristics for all receivers
within some range. An example is a stock price feed, where it
unacceptable for a receiver to suffer delivery that is
significantly more than any other receiver
This requirement is difficult to satisfy without harming performance
Typically solutions involve not sending more than a limited amount
new data until positive acknowledgments have been received from
the receivers. Such a solution does not cope with network and end
system failures well
2.3. Receiver Set
There are many applications for RM that do not need to scale to
numbers of receivers. For such applications, a range of
may be available that are not available for applications
scaling to large receiver sets is a requirement
A protocol must achieve good throughput of application data units
receivers. This means that most data that is delivered to
is useful in recovering the application data unit that they
trying to receive. A protocol must also provide good
control to fairly share the available network resources between
applications. Receiver set scaling is one of the most
constraints in meeting these requirements, because it strictly
the mechanisms that can be used to achieve these requirements
those that will efficiently scale to a large receiver population
Acknowledgement packets have been employed by many systems to
these goals, but it is important to understand the strength
limitations of different ways of using such packets
In a very small system, it may be acceptable to have the
acknowledge every packet. This approach provides the sender with
maximum amount of information about reception conditions at all
receivers, information that can be used both to achieve
throughput and to achieve congestion control
Handley, et al. Informational [Page 4]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
For larger systems, such "flat ACK" schemes cause
implosions at the sender. Attempts have been made to reduce
problem by sending aggregate ACKs infrequently [RMWT98, BC94], but
is very difficult to incorporate effective congestion control
such protocols because of the spareceness of feedback
Using negative acknowledgments (NACKs) instead of ACKs reduces
problem to one of NACK implosion (only from the receivers missing
packets), and because the sender really only needs to know that
least one receiver is missing data in order to achieve
throughput, various NACK suppression mechanisms can be applied
An alternative to NACKs is ACK aggregation, which can be done
arranging the receivers into a logical tree, so that each leaf
ACKs to its parent which aggregates them, and passes them on up
tree. Tree-based protocols scale well, but tree formation can
problematic
Other ACK topologies such as rings are also possible, but are
more difficult to form and maintain than trees are. An
strategy is to add mechanisms to routers so that they can help out
achieving good throughput or in reducing the cost of achieving
throughput
All these solutions improve receiver set scaling, but they all
limits of one form or another. One class of solutions scales to
infinite number of receivers by having no feedback channel
in order to achieve good throughput. These open-loop solutions
the initial data and encode it using an FEC-style mechanism.
encoded data is transmitted in a continuous stream. Receivers
join the session and receive packets until they have
packets to decode the original data, at which point they leave
session
Thus, it is clear that the intended scale of the session
the possible solutions. All solutions will work for very
sessions, but as the intended receive set increases, the range
possible solutions that can be deployed safely decreases
It should also be noted that hybrids of these mechanisms
possible, and that using one mechanism at the packet-level and
different (typically higher overhead) solution at the ADU level
also scale reasonably if the ADUs are large compared to packets
Handley, et al. Informational [Page 5]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
2.4. Total vs Semi-
Many applications require delivery of application data units to
totally reliable; if any of the application data unit is missing
none of the received portion of the application data unit is useful
File transfer applications are a good example of
requiring total reliability
However, some applications do not need total reliability. An
is audio broadcasting, where missing packets reduce the quality
the received audio but do not render it unusable. Such
can sometimes get by without any additional reliability over
IP reliability, but often having a semi-reliable multicast
is desirable
2.5. Time-bounded
Many applications just require data to be delivered to the
as fast as possible. They have no absolute deadline for delivery
However, some applications have hard delivery constraints - if
data does not arrive at the receiver by a certain time, there is
point in delivering it at all. Such time-boundedness may be as
result of real-time constraints such as with audio or
streaming, or as the result of new data superseding old data.
both cases, the requirement is for the application to have a
degree of control over precisely what the application sends at
time than might be required with applications such as file transfer
Time-bounded delivery usually also implies a semi-reliable protocol
but the converse does not necessarily hold
3. Network
The properties of the network in which the application is
deployed may themselves constrain the reliable multicast
space
3.1. Internet vs
In principle the Internet and intranets are the same. In
however, the fact that an intranet is under one administration
allow for solutions to be configured that can not easily be done
the public Internet. Thus, if the data is of very high value,
might be appropriate to enhance the routers to provide assistance
a reliable multicast transport protocol. In the public Internet,
is less likely that the additional expense required to support
state in the routers would be acceptable
Handley, et al. Informational [Page 6]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
3.2. Return
In principle, when feedback is required from receivers, this
can be multicast or unicast. Multicast feedback has advantages
especially in NACK-based protocols where it is valuable for
suppression. However, it is not clear at this time whether all
will allow all members of a session to send to that session.
multicast feedback is not allowed, then unicast feedback can
always be substituted, although often at the expense of
messages and mechanisms
Some networks may not allow any form of feedback however.
primary example of this occurs with satellite broadcasts where
back channel may be very narrow or even non-existent. For
networks the solution space is very constrained - only FEC-
encodings have any real chance of working. If the receivers
direct satellite receivers, then no congestion control is needed,
it is dangerous to make such assumptions because it is possible for
satellite hop to feed downstream networks. Thus, congestion
still needs to be considered with solutions that do not have a
path
3.3. Network
A reliable multicast protocol must involve mechanisms running in
hosts, and must involve routers forwarding multicast packets
However under some circumstances, it is possible to rely on
additional degree of assistance from network elements.
speaking we can cluster RM protocols into four classes depending
the degree of support received from other network elements
No Additional
The routers merely forward packets, and only the sender
receivers have any reliable multicast protocol state
Layered
Data is split across multiple multicast groups. Receivers
appropriate groups to receive only the traffic they require.
may in some cases require fast join or leave functionality
the routers, and may require more forwarding state in the routers
Server-based
Additional nodes are used to assist with data delivery or
aggregation. These additional nodes might not be normal
or receivers, and may be present on the distribution or
tree only to provide assistance to the reliable
protocol. They would not otherwise receive the multicast traffic
Handley, et al. Informational [Page 7]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
Router-based
With router-based approaches, routers on the normal
distribution tree from the sender to the receivers assist in
delivery of data or feedback aggregation or suppression.
routers can directly influence multicast routing, they have
control over which traffic goes to which group members
server-based approaches. However routers do not normally have
large amount of spare memory or processing power, which
how much functionality can be placed in the routers. In addition
router code is normally more difficult to upgrade than
code, so router-based approaches need to be very general as
are more difficult to deploy and to change
4. Good Throughput
Two main concerns that a RM protocol must address are
control and good throughput. Packet loss plays a major role
respect to both concerns. The primary symptom of congestion in
networks is packet loss. The primary obstacle that must be
to achieve good throughput is packet loss. Thus, measuring
reacting to packet loss is crucial to address both concerns.
solutions that address these concerns can be roughly categorized
using one or more of the following techniques
o Data packet acknowledgment
o Negative acknowledgment of missing data packets
o Redundancy allowing not all packets to be received
These techniques themselves can be usefully subdivided, so that
can examine the parts of the requirement space in which
mechanism can be deployed. In this section, we focus on using
mechanisms for achieving good throughput, and in the next section
focus on using these mechanisms for congestion control
4.1. ACK-based
The simplest ACK-based mechanism involves every receiver sending
ACK packet for every data packet it receives and resending
that are lost by any receiver. Such mechanisms are limited to
small receiver groups by the implosion of ACKs received at
sender, and for this reason they are impractical for
applications
Handley, et al. Informational [Page 8]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
Putting multiple ACKs into a single data packet [RMWT98] reduces
implosion problem by a constant amount, allowing slightly
receiver groups. However a limit is soon reached whereby feedback
the sender is too infrequent for sender-based congestion
mechanisms to work reliably
Arranging the receivers into a ring [WKM94] whereby an "ACK-token"
passed around the ring prevents the implosion problem for data
However ring creation and maintenance may itself be problematic
Also if ring creation does not take into account network
(something which is difficult to achieve in practice), then
number of ACK packets crossing the network backbone for each
packet sent may increase O(n) with the number of receivers
4.1.1. Tree-based ACK
Arranging the receivers into a tree [MWB+98, KCW98] whereby
generate ACKs to a parent node, which aggregates those ACKs to
parent in turn, is both more robust and more easily configured than
ring. The ACK-tree is typically only used for ACK-aggregation -
packets are multicast from the sender to the receivers as normal
Trees are easier to construct than rings because more
information can be used in their construction. Also they can be
fault tolerant than rings because node failures only affect a
of receivers, each of which can easily and locally decide to by-
its parent and report directly to the node one level higher in
tree. With good ACK-tree formation, tree-based ACK mechanisms
the potential to be one of the most scalable RM solutions
To be simple to deploy, tree-based protocols must be self-
- the receivers must form the tree themselves using local
in a scalable manner. Such mechanisms are possible, but are
trivial. The main scaling limitations of tree-based
therefore come from the tree formation and maintenance
rather than from the use of ACKs. Without such a scalable
automatic tree-formation mechanism, tree-based protocols must rely
manual configuration, which significantly limits their
(often to intranets) and (due to the complexity of configuration
their scalability
Orthogonal to the issue of tree formation is the issue of
retransmission. With appropriate router mechanisms, or the use
multiple multicast groups, it is possible to allow the
tree nodes to retransmit missing data to the nodes below them in
tree rather than relying on the original sender to retransmit
data. This relies on there being a good correlation at the point
the intermediate node between the ACK tree and the actual data tree
as well as there being a mechanism to constrain the retransmission
Handley, et al. Informational [Page 9]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
the subtree. A good automatic tree formation mechanism combined
the use of administrative scoped multicast groups might provide
a solution. Without such tree formation mechanisms,
retransmission is difficult to deploy in large groups in the
internet. This could also be solved by the use of transport
level router mechanisms to assist or perform retransmission,
existing router mechanisms [FLST98] support NACK-based rather
ACK-based protocols
Another important issue is the nature of the aggregation performed
interior nodes on the ACK-tree. Such nodes could
1. aggregate ACKs by sending a single ACK when all their
have ACKed
2. aggregate ACKs by listing all the children that have ACKed
3. send an aggregated ACK with a NACK-like exception list
For data packets, 1. is clearly more scalable, and should
preferred. However if the sender needs to know exactly
receivers received the data, 2. and 3. provide this information
Fortunately, there is usually no need to do this on a per-
basis, but rather on a per-ADU basis. Doing 1. on a per
basis, and 3. on a per ADU basis is the most scalable solution
applications that need this information, and suffers virtually
disadvantage compared to the other solutions used on a per-
basis
4.2. NACK-based
Instead of sending an ACK for every data packet received,
can send a negative acknowledgment (NACK) for every data packet
discover they did not receive. This has a number of advantages
ACK-based mechanisms
o The sender no longer needs to know exactly how many
there are. This removes the topology-building phase needed
ring- or tree-style ACK-based algorithms
o Fault-tolerance is made somewhat simpler by making
responsible for reliability
o Sender state can be significantly reduced because the sender
not need to keep track of the receivers state
Handley, et al. Informational [Page 10]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
o Only a single NACK is needed from any receiver to indicate
packet that is missing by any number of receivers. Thus
suppression is possible
The disadvantages are that it is more difficult for the sender
know that it can free transmission buffers, and that
session level mechanisms are needed if the sender really needs
know if a particular receiver actually received all the data
However for many applications, neither of these is an issue
4.2.1. NACK
The key differences between NACK-based protocols is in how NACK
suppression is performed. The goal is for only one NACK to reach
sender (or a node that can resend the missing data) as soon
possible after the loss is first noticed, and for only one copy
the missing data to be received by those nodes
retransmission
Different mechanisms come close to satisfying these goals
different ways
o SRM [FJM95] uses random timers weighted by the round trip
between the sender and each node missing the data. This
effective, but requires computing the RTT to each receiver
suppression works properly
o NTE [HC97] uses a sender-triggered mechanism based on random
and sliding masks. This does not require random timers, and
for very large sessions, but makes it difficult to provide
constant low-level stream of feedback needed to perform
control
o AAP [Ha99] uses exponentially distributed random timers and
effective for large sessions without needing to compute the RTT
each receiver
o PGM [FLST98] and LMS [PPV98] use additional mechanisms in
to suppress duplicate NACKs. In the case of PGM,
assistance suppliments SRM-stype random timers and localizes
suppression so that the whole group does not need suppressing
The most general of these mechanisms is probably
weighted random timers. Although SRM style timers can
feedback delay, they are harder to use correctly in situations
all the RTTs are not known, or where the number of respondees
Handley, et al. Informational [Page 11]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
unknown. In contrast, exponentially weighted random timers work
across a large range of session sizes with good worst case
characteristics
Either form of random timer based mechanism can be supplemented
router-support where it is available. Sender triggered
mechanisms (e.g. [HC97]) are more difficult to integrate
router-based support mechanisms
4.3.
Some RM protocols can be designed so as to not need
reliability mechanisms except in comparatively rare cases.
example is in a multicast game, where the position of a moving
is continuously multicast. This positional stream does not
additional reliability because a new position superseding the old
will be sent before any retransmission could take place. However
when the moving object interacts with other objects or stops moving
then an explicit reliability mechanism is required to reliably
the interaction information or last position
It is not just games that can be built in this manner - the
shared text editor[HC97] uses just such a mechanism with changes to
line of text. For every change the whole line is sent, and so
as the user keeps typing no explicit reliability mechanism is needed
The major advantage of replication is that it is not susceptible
spatially uncorrelated packet loss. With a traditional ACK or
based protocol, the probability of any particular packet
received by all the receivers in a large group can be very low.
leads to high retransmission rates. In contrast,
streams do not suffer as the size of the receiver group increases -
different receivers lose different packets, but this does
increase network traffic
4.4. Packet-level Forward Error
Forward Error Correction (FEC) is a well known technique
protecting data against corruption. For reliable multicast it
most useful in the form of erasure codes
The simplest form of packet-level FEC is to take a group of
that is to be sent, and to XOR the packets together to form
newpacket which is also sent. If there were three original
plus the XOR packet sent, then if a receiver is missing any one
the original data packets, but receives the XOR packet, then it
reproduce the missing original packet
Handley, et al. Informational [Page 12]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
More general erasure codes exist [BKKKLZ95], [Ri97], [LMSSS97]
allow the generation of n encoding packets from k original
packets. In such cases, so long as at least k of the n
packets are received, then the k original data packets can
reproduced
To apply FEC the sender groups data packets into rounds, and
packets are produced based on all the data packets in a round.
round may consist of all data packets in an entire application
unit in some cases, whereas in other cases it may consist of a
of data packets that make up only a small portion of an
data unit
Using erasure codes to repair packet loss is a
improvement over simple retransmission because the dependency
which packets have been lost is removed. Thus, the amount of
traffic required to repair spatially uncorrelated packet loss
considerably lessened
We can divide packet-level FEC schemes into two categories:
FEC and reactive FEC. The difference between the two is that
proactive FEC the sender decides a priori how many encoding
to send for each round of data packets, whereas for reactive FEC
sender initially transmits only the original data packets for
round. Then, the sender uses feedback from the receivers to
how many packets were lost by the receiver that experienced the
loss in each round, and then only that number of additional
packets are sent for that round. These encoding packets will
also serve to repair loss at the other receivers that are
fewer packets. The receivers report via ACKs or NACKs how
packets are missing from each round. With NACKs, only the
missing the most packets need send a NACK for this round, so this
used to weight the random timers in the NACK calculation
Proactive and reactive FEC can be combined, e.g., a certain amount
proactive FEC can be sent for each round and if there are
that experience more loss than can be overcome by this for
rounds then they can request and receive additional encoding
for these rounds
FEC is very effective at reducing the repair traffic for packet loss
However, it requires that the data to be sent to be grouped
rounds, which can add to end-to-end latency. For bulk-
applications this is typically not a problem, but this may be
issue for interactive applications where replication may be a
solution
Handley, et al. Informational [Page 13]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
4.5. Layered
An alternative use of packet level FEC is possible when data
spread across several multicast groups [RVC98], [BLMR98]. In
cases, the original k data packets are used to generate n
packets, where n is much larger than k. The n encoded packets
then striped across multiple multicast groups. When a
wishes to receive the original data it joins one or more of
multicast groups, and receives the encoding packets. Once it
received k different encoding packets, the receiver can then
all the multicast groups and reconstruct the original data
The primary importance of such a layering is that it allows
receivers to be able to receive the traffic at different
according to the available capacity. Such schemes do not require
form of feedback from the receivers to the sender to ensure
throughput, and therefore the need for good throughput does
constrain the size of the receiver set. However, to perform
network congestion control using receiver joins and leaves in
manner may require coordination between members that are behind
same congested link from the sender. As described in the
section, [RVC98] suggests such a layered congestion control scheme
5. Congestion Control
The basic delivery model of the Internet is best-effort service.
guarantees are given as to throughput, delay or packet loss. End
systems are expected to be adaptive, and to reduce their
rate to a level appropriate for the congestion state of the network
Although increasingly the Internet will start to support
bandwidth and differentiated service classes for
applications, unless an end-system knows explicitly that it
reserved bandwidth, it must still perform congestion control
Broadly speaking, there are five classes of single-sender
congestion control solution
o Sender-controlled, one group
A single multicast group is used for data distribution.
from the group members is used to control the rate of this group
The goal is to transmit at a rate dictated by the
receiver
Handley, et al. Informational [Page 14]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
o Sender-controlled, multiple groups
One initial multicast group is adaptively subdivided into
subgroups with subdivisions centered on congestion points in
network. Application-level relays buffer data from a group
the original sender, and retransmit it at a slower rate into
group further from the original sender. In this way,
receivers can receiver the data at different rates. Sender-
congestion control takes place between the members of a
and their relay
o Receiver-controlled, one group
A single multicast group is used for data distribution.
receivers determine if the sender is transmitting too rapidly
the current congestion state of the network, and they leave
group if this is the case
o Receiver-controlled, layered organization
A layered approach for how to combine this scheme with
congestion control protocol that requires no receiver feedback
described in [RVC98]. The sender stripes data across
multicast groups simultaneously. Receivers join and leave
layered groups depending on their measurements of the
state of the network, so that the amount of data being received
always appropriate. However, this scheme relies on receivers
join and leave the different multicast groups in a
fashion behind a bottleneck link, and it has not yet
completely confirmed that this approach will scale in practice
the Internet. As a result, more work on this congestion
mechanism would be beneficial
o Router-based congestion control
It is possible to add additional mechanisms to multicast
to assist in multicast congestion control. Such mechanisms
include
o Conditional joins (a multicast join that specifies a loss
above which it is acceptable for the router to reject
join).
o Router filtering of traffic that exceeds a reasonable rate
This may include mechanisms for filtering traffic at
points in the network at different rates depending on
congestion conditions [LVS99].
Handley, et al. Informational [Page 15]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
o Fair queuing schemes combined with end-to-end adaptation
Router-based schemes generally require more state in
routers than has traditionally been acceptable for
routers. Thus, in the near-term, such schemes are only likely
be applicable for intranet solutions
For reliable multicast protocols, it is important to
congestion control at the same time as reliability is
considered. The same mechanisms that are used to provide
will sometimes be used to provide congestion control
In the case of receiver-based congestion control, open-loop
using FEC is the likely choice for achieving good throughput
bulk- data transfer. This is because open-loop delivery requires
feedback from receivers, and thus it is a perfect match with
receiver-based congestion-control mechanism that operates
feedback from receivers
6. Security
Generally speaking, security considerations have relatively
effect on constraining the design space for reliable
protocols. The primary issues constraining the design space are
related to receiver-set scaling. For authentication of the
and of data integrity, receiver-set scaling is not a
issue. However, for data encryption, key distribution
particularly re-keying may be significantly affected by receiver-
scaling. Tree and graph based re-keying solutions[WHA98,WGL97]
appear to be appropriate solutions to these problems. It is
clear however that such re-keying solutions need to directly
the design of the data distribution part of a reliable
protocol
The primary question to consider for the security of
multicast protocols is the role of third-parties. If nodes
than the original source of the data are allowed to send or
data packets, then the security model for the protocol must take
into account. In particular, it must be clear whether such
parties are trusted or untrusted. A requirement for trusted
parties can make protocols difficult to deploy on the Internet
Untrusted third parties (such as receivers that retransmit the data
may be used so long as the data authentication mechanisms take
into account. Typically this means that the original
digitally signs and timestamps the data, and that the third
resend this signed timestamped payload unmodified
Handley, et al. Informational [Page 16]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
Unlike unicast protocols, denial-of-service attacks on
transport state are easy if the protocol design does not take
attacks into account. This is because any receiver can join
session, and can then produce feedback that influences the
of a session involving many other receivers. Hence
against denial-of-service attacks on reliable multicast
must be carefully considered. A receiver that
retransmission of every packet, or that refuses to
packets in an ACK-based protocol can potentially bring a
multicast session to a standstill. Senders must have
policy to deal with such conditions, and if necessary, evict
receiver from the group. A single receiver masquerading as a
number of receivers may still be an issue under such
with protocols that support NACK-like functionality.
unique "keys" to each NACKer when they first NACK using a
response might potentially prevent such attacks
Denial-of-service attacks caused by traffic flooding are
somewhat easier to protect against than with unicast.
senders can simply be pruned from the distribution tree using
mechanisms implemented in IGMP v3[CDT99].
7.
In this document we present an overview of the design space
reliable multicast within the context of one-to-many bulk-
transfer. Other flavors of multicast application are not
in this document, and hence the overview given should not
considered inclusive of the design space for protocols that
outside the context of one-to-many bulk-data transfer. During
course of this overview, we have reaffirmed the notion that
process of reliable multicast protocol design is affected by a
of factors that render the generation of a "one size fits
solution" moot. These factors are then described to show how
application's needs serve to constrain the set of
techniques that may be used to create a reliable multicast protocol
We examined a number of basic techniques and to show how well
can meet the needs of certain types of applications
This document is intended to provide guidance to the IETF
regarding the standardization of reliable multicast protocols
bulk-data transfer. Given the degree to which
requirements constrain reliable multicast solutions, and the
set of applications that need to be supported, it should be
that any standardization work should take great pains to be future
proof. This would seem to imply not standardizing complete
multicast transport protocols in one pass, but rather examining
degree to which such protocols are separable into functional
Handley, et al. Informational [Page 17]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
blocks, and standardizing these blocks separately to the
degree that makes sense. Such an approach allows for
evolution, and allows applications with new constraints to
supported with maximal reuse of existing and tested mechanisms
8.
This document represents an overview of the reliable multicast
space. The ideas presented are not those of the authors, but
collected from the varied presentations and discussions in the
Reliable Multicast Research Group. Although they are too numerous
list here, we thank everyone who has participated in
discussions for their contributions
9. Authors'
Mark
ATT Center for Internet Research at ICSI
International Computer Science Institute
1947 Center Street, Suite 600,
Berkeley, CA 94704,
EMail: mjh@aciri.
Sally
ATT Center for Internet Research at ICSI
International Computer Science Institute
1947 Center Street, Suite 600,
Berkeley, CA 94704,
EMail: floyd@aciri.
Brian
Talarian Corporation
333 Distel Circle
Los Altos, CA 94022,
EMail: whetten@talarian.
Handley, et al. Informational [Page 18]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
Roger
Motorola Australian Research
Level 3, 12 Lord St
Botany NSW 2019,
EMail: Roger.Kermode@motorola.
Lorenzo
Cisco Systems
170 West Tasman Dr
San Jose, CA 95134,
EMail: lorenzo@cisco.
Michael
Digital Fountain, Inc
600 Alabama
San Francisco, CA 94110
EMail: luby@digitalfountain.
10.
[BC94] K. Birman, T. Clark. "Performance of the Isis
Computing Toolkit." Technical Report TR-94-1432, Dept.
Computer Science, Cornell University
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D
Zuckerman, "An XOR-based Erasure Resilient Coding Scheme",
ICSI Technical Report No. TR-95-048, August 1995.
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A
Fountain Approach to Reliable Distribution of Bulk Data",
Proc ACM SIGCOMM 98.
[CDT99] Cain, B., Deering, S., and A. Thyagarajan, "Internet
Management Protocol, Version 3", Work in Progress
[FLST98] Farinacci, D., Lin, S., Speakman, T. and A. Tweedly, "
reliable transport protocol specification", Work
Progress
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable
Framework for Light-weight Sessions and Application
Framing", Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
Handley, et al. Informational [Page 19]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
[Ha99] Handley, M., "Multicast address allocation
(AAP)", Work in Progress
[HC97] M. Handley and J. Crowcroft, "Network text editor (NTE)
scalable shared text editor for MBone," ACM
Communication Review, vol. 27, pp. 197-208, Oct. 1997.
SIGCOMM'97, Sept. 1997.
[KCW98] Kadansky, M., Chiu, D. and J. Wesley, "Tree-based
multicast (TRAM)", Work in Progress
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V
Stemann, "Practical Loss-Resilient Codes", Proc
Symposium on Theory of Computing, 1997.
[MWB+98] Montgomery, T., Whetten, B., Basavaiah, M., Paul, S.,
Rastogi, N., Conlan, J. and T. Yeh, "THE RMTP-
PROTOCOL", Work in Progress
[PPV98] C. Papadopoulos, G. Parulkar, and G. Varghese, "An
control scheme for large-scale multicast applications,"
Proceedings of the Conference on Computer
(IEEE Infocom), (San Francisco, California), p. 1188,
March/April 1998.
[Ri97] L. Rizzo, "Effective erasure codes for reliable
communication protocols," ACM Computer
Review, vol. 27, pp. 24-36, Apr. 1997.
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast
Distribution Protocol based on software FEC techniques",
Proc. of The Fourth IEEE Workshop on the Architecture
Implementation of High Performance Communication
(HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25,
1997.
[RVC98] L. Rizzo, L. Vicisano, J. Crowcroft, "The RLC
congestion control algorithm", submitted to IEEE Network -
special issue multicast
[RMWT98] Robertson, K., Miller, K., White, M. and A. Tweedly
"StarBurst multicast file transfer protocol (MFTP
specification", Work in Progress
[WHA98] Wallner, D., Hardler, E. and R. Agee, "Key Management
Multicast: Issues and Architectures", RFC 2627, June 1999.
Handley, et al. Informational [Page 20]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
[WKM94] Brian Whetten, Simon Kaplan, and Todd Montgomery, "A
performance totally ordered multicast protocol,"
memorandum, Aug. 1994.
[WGL97] C.K. Wong, M. Gouda, S. Lam, "Secure Group
Using Key Graphs," Technical Report TR 97-23,
of Computer Sciences, The University of Texas at Austin
July 1997.
Handley, et al. Informational [Page 21]
RFC 2887 Multicast Design Space for Bulk Data Transfer August 2000
11. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Handley, et al. Informational [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
