draft-ietf-mmusic-confarch-02.txt   draft-ietf-mmusic-confarch-03.txt 
INTERNET-DRAFT M. Handley/J. Crowcroft/C. Bormann/J. Ott INTERNET-DRAFT M. Handley/J. Crowcroft/C. Bormann/J. Ott
Expires: April 2000 ISI/UCL/TZI/TZI Expires: January 2001 ACIRI/UCL/TZI/TZI
October 1999 July 2000
The Internet Multimedia Conferencing Architecture The Internet Multimedia Conferencing Architecture
draft-ietf-mmusic-confarch-02.txt draft-ietf-mmusic-confarch-03
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 4, line 45 skipping to change at page 5, line 7
| Integrated Services Forwarding | | Integrated Services Forwarding |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
The protocol stacks for internet multimedia conferencing are The protocol stacks for internet multimedia conferencing are
illustrated in Figure 1. Most of the protocols are not deeply illustrated in Figure 1. Most of the protocols are not deeply
layered unlike many protocol stacks, but rather are used alongside layered unlike many protocol stacks, but rather are used alongside
each other to produce a complete conference. each other to produce a complete conference.
3. Multicast Traffic Distribution 3. Multicast Traffic Distribution
+--------------+------------------+---------------------------------------------+ +--------------+------------------+-----------------------------------+
|Protocol | Documentation | Purpose | |Protocol | Documentation | Purpose |
+--------------+------------------+---------------------------------------------+ +--------------+------------------+-----------------------------------+
|IP Multicast | RFC 1112, 2236 | Host extensions for IP Multicast | |IP Multicast | RFC 1112, 2236 | Host extensions for IP Multicast |
|DVMRP | RFC 1075 | Dense-mode Intra-domain multicast routing | | | | Multicast routing protocols: |
|PIM-SM | RFC 2362 | Sparse-mode Intra-domain multicast routing | |DVMRP | RFC 1075 | Dense-mode Intra-domain |
|PIM-SM | RFC 2362 | Sparse-mode Intra-domain |
| | | | |PIM-DM | Internet Draft | Dense-mode Intra-domain |
|PIM-DM | Internet Draft | Dense-mode Intra-domain multicast routing | |CBT | RFC 2189 | Sparse-mode Intra-domain |
|CBT | RFC 2189 | Sparse-mode Intra-domain multicast routing | +--------------+------------------+-----------------------------------+
+--------------+------------------+---------------------------------------------+
IP multicast provides efficient many-to-many data distribution in an IP multicast provides efficient many-to-many data distribution in an
internet environment. It is easy to view IP multicast as simply an internet environment. It is easy to view IP multicast as simply an
optimization for data distribution, and indeed this is the case, but optimization for data distribution, and indeed this is the case, but
IP multicast can also result in a different way of thinking about IP multicast can also result in a different way of thinking about
application design. To see why this might be the case, examine the application design. To see why this might be the case, examine the
IP multicast service model, as described by Van Jacobson [8]: IP multicast service model, as described by Van Jacobson [8]:
- Senders just send to the group - Senders just send to the group
skipping to change at page 5, line 51 skipping to change at page 6, line 6
23]. Typically, as a group with s senders and r receivers increases 23]. Typically, as a group with s senders and r receivers increases
in size, state in routers scales O(s) or O(1) depending on the in size, state in routers scales O(s) or O(1) depending on the
routing scheme in use. This state may be in on-tree routers for routing scheme in use. This state may be in on-tree routers for
newer so called sparse-mode algorithms such as PIM, or in off-tree newer so called sparse-mode algorithms such as PIM, or in off-tree
routers for older so-called dense-mode algorithms such as DVMRP. routers for older so-called dense-mode algorithms such as DVMRP.
Thus the most scalable current multicast routing algorithms require Thus the most scalable current multicast routing algorithms require
O(1) state in on-tree routers, and hence the total routing state O(1) state in on-tree routers, and hence the total routing state
scales O(g) in a router that is on-tree for g groups. We can also scales O(g) in a router that is on-tree for g groups. We can also
envisage multicast routing schemes which require less than O(g) envisage multicast routing schemes which require less than O(g)
state*, but the requirement is not currently urgent, so none of these state*, but the requirement is not currently urgent, so none of these
_________________________
* with IP encapsulation, not all on-tree routers need hold the
state for a group whose traffic they are forwarding -- traffic for
the group can be encapsulated (either unicast of multicast) be-
tween on-tree routers nearer the edge of the network, reducing
some of the state burden on backbone routers.
have yet been implemented. have yet been implemented.
The level of indirection introduced by the IP class D address The level of indirection introduced by the IP class D address
denominating the group solves the distributed systems binding denominating the group solves the distributed systems binding
problem, by pushing this task down into routing; given a multicast problem, by pushing this task down into routing; given a multicast
address (and UDP port), a host can send a message to the members of a address (and UDP port), a host can send a message to the members of a
group without needing to discover who they are. Similarly receivers group without needing to discover who they are. Similarly receivers
can ``tune in'' to multicast data sources without needing to bother can ``tune in'' to multicast data sources without needing to bother
the data source itself with any form of request. the data source itself with any form of request.
skipping to change at page 6, line 31 skipping to change at page 6, line 32
broadcast-style sessions, it is essential that data-replication be broadcast-style sessions, it is essential that data-replication be
carried out in a way that only requires per-receiver network-state to carried out in a way that only requires per-receiver network-state to
be local to each receiver, and that data-replication occurs within be local to each receiver, and that data-replication occurs within
the network. Attempting to configure a tree of application-specific the network. Attempting to configure a tree of application-specific
replication servers for such broadcasts rapidly becomes a ``multicast replication servers for such broadcasts rapidly becomes a ``multicast
routing'' problem, and thus native multicast support is a more routing'' problem, and thus native multicast support is a more
appropriate solution. appropriate solution.
3.1. Address Allocation 3.1. Address Allocation
+----------+-------------------+---------------------------------------------------+ +----------+-------------------+----------------------------------+
|Protocol | Documentation | Purpose | |Protocol | Documentation | Purpose |
+----------+-------------------+---------------------------------------------------+ +----------+-------------------+----------------------------------+
|MADCAP | Internet Draft | DHCP-like client protocol for address allocation | |MADCAP | Internet Draft | DHCP-like client protocol |
| | | for address allocation |
|AAP | Internet Draft | Intra-domain address allocation | |AAP | Internet Draft | Intra-domain address allocation |
|MASC | Internet Draft | Inter-domain address allocation | |MASC | Internet Draft | Inter-domain address allocation |
|BGMP | Internet Draft | Inter-domain multicast routing | |BGMP | Internet Draft | Inter-domain multicast routing |
+----------+-------------------+---------------------------------------------------+ +----------+-------------------+----------------------------------+
How does an application choose a multicast address to use? How does an application choose a multicast address to use?
In the absence of any other information, we can bootstrap a multicast In the absence of any other information, we can bootstrap a multicast
application by using well-known multicast addresses. Routing application by using well-known multicast addresses. Routing
(unicast and multicast) and group membership protocols [5] can do (unicast and multicast) and group membership protocols [5] can do
_________________________
* with IP encapsulation, not all on-tree routers need hold the
state for a group whose traffic they are forwarding -- traffic for
the group can be encapsulated (either unicast of multicast) be-
tween on-tree routers nearer the edge of the network, reducing
some of the state burden on backbone routers.
just that. However, this is not the best way of managing just that. However, this is not the best way of managing
applications of which there is more than one instance at any one applications of which there is more than one instance at any one
time. time.
For these, we need a mechanism for allocating group addresses For these, we need a mechanism for allocating group addresses
dynamically, and a directory service which can hold these allocations dynamically, and a directory service which can hold these allocations
together with some key (session information for example --- see together with some key (session information for example --- see
later), so that users can look up the address associated with the later), so that users can look up the address associated with the
application. The address allocation and directory functions should application. The address allocation and directory functions should
be distributed to scale well. be distributed to scale well.
skipping to change at page 7, line 43 skipping to change at page 7, line 54
router exceeds a queue size limit due to congestion. The best-effort router exceeds a queue size limit due to congestion. The best-effort
internet service model does not assume FIFO queuing, although many internet service model does not assume FIFO queuing, although many
routers have implemented this. routers have implemented this.
With best-effort service, if a link is not congested, queues will not With best-effort service, if a link is not congested, queues will not
build at routers, datagrams will not be discarded in routers, and build at routers, datagrams will not be discarded in routers, and
delays will consist of serialization delays at each hop plus delays will consist of serialization delays at each hop plus
propagation delays. With sufficiently fast link speeds, propagation delays. With sufficiently fast link speeds,
serialization delays are insignificant compared to propagation serialization delays are insignificant compared to propagation
delays*. delays*.
_________________________
* For slow links, a set of mechanisms has been defined that
If a link is congested, with best-effort service, queuing delays will If a link is congested, with best-effort service, queuing delays will
start to influence end-to-end delays, and packets will start to be start to influence end-to-end delays, and packets will start to be
lost as queue size limits are exceeded. Real-time traffic does not lost as queue size limits are exceeded. Real-time traffic does not
cope terribly well with packet loss levels of more than a few cope terribly well with packet loss levels of more than a few
percent, although it is possible to add redundancy [12] to increase percent, although it is possible to add redundancy [12] to increase
the levels at which loss becomes a problem. In the last few years a the levels at which loss becomes a problem. In the last few years a
significant amount of work has also gone into providing non-best- significant amount of work has also gone into providing non-best-
effort services that would provide a better assurance that an effort services that would provide a better assurance that an
_________________________
* For slow links, a set of mechanisms has been defined that
helps minimize serialization and link access delays [2].
acceptable quality conference will be possible. acceptable quality conference will be possible.
4.1. Non-best effort service 4.1. Non-best effort service
Real-time internet traffic is defined as datagrams that are delay Real-time internet traffic is defined as datagrams that are delay
sensitive. It could be argued that all datagrams are delay sensitive sensitive. It could be argued that all datagrams are delay sensitive
to some extent, but for these purposes we refer only to datagrams to some extent, but for these purposes we refer only to datagrams
where exceeding an end-to-end delay bound of a few hundred where exceeding an end-to-end delay bound of a few hundred
milliseconds renders the datagrams useless for the purpose they were milliseconds renders the datagrams useless for the purpose they were
intended. For the purposes of this definition, TCP traffic is intended. For the purposes of this definition, TCP traffic is
skipping to change at page 8, line 47 skipping to change at page 8, line 53
service something like that shown in Figure 2. service something like that shown in Figure 2.
Figure 2: Spectrum of internet service types Figure 2: Spectrum of internet service types
best effort assured by guaranteed by best effort assured by guaranteed by
unsignalled type of service per-flow reservation unsignalled type of service per-flow reservation
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
prioritized by assured by prioritized by assured by
type of service aggregate reservation type of service aggregate reservation
_________________________
helps minimize serialization and link access delays [2].
This spectrum is intended to illustrate that between best-effort, and This spectrum is intended to illustrate that between best-effort, and
hard per-flow guarantees lie many possibilities for non-best-effort hard per-flow guarantees lie many possibilities for non-best-effort
service, including having hard guarantees based on an aggregate service, including having hard guarantees based on an aggregate
reservation, assurances that traffic marked with a particular type- reservation, assurances that traffic marked with a particular type-
of-service bit will not be dropped so long as it remains in profile, of-service bit will not be dropped so long as it remains in profile,
and simpler prioritization-based services. and simpler prioritization-based services.
Towards the right hand side of the spectrum, flows are typically Towards the right hand side of the spectrum, flows are typically
identifiable in the Internet by the tuple: source machine, identifiable in the Internet by the tuple: source machine,
destination machine, source port, destination port, protocol, any of destination machine, source port, destination port, protocol, any of
skipping to change at page 9, line 46 skipping to change at page 10, line 5
individual call need be given an allocation (i.e. we would no longer individual call need be given an allocation (i.e. we would no longer
need the call setup/tear down that was needed in the legacy POTS need the call setup/tear down that was needed in the legacy POTS
which was only present due to under-provisioning of trunks, and to which was only present due to under-provisioning of trunks, and to
allow the trunk exchanges the option of call blocking). The vision allow the trunk exchanges the option of call blocking). The vision
is of a network that is engineered with capacity for all of the non- is of a network that is engineered with capacity for all of the non-
best-effort average load sources to send without needing individual best-effort average load sources to send without needing individual
reservations. reservations.
4.2. Reservations 4.2. Reservations
+-------------------------+----------------+-----------------------------------------+ +-----------------+----------------+---------------------------------------+
|Protocol | Documentation | Purpose | |Protocol | Documentation | Purpose |
+-------------------------+----------------+-----------------------------------------+ +-----------------+----------------+---------------------------------------+
|RSVP | RFC 2205 | Resource ReSerVation Protocol (RSVP) | |RSVP | RFC 2205 | Resource ReSerVation Protocol (RSVP) |
|Controlled Load Service | RFC 2211 | Network service model selected by RSVP | |Controlled Load | RFC 2211 | Network service model |
|Guaranteed Service | RFC 2212 | Network service model selected by RSVP | | Service | | selected by RSVP |
+-------------------------+----------------+-----------------------------------------+ |Guaranteed | RFC 2212 | Network service model |
| Service | | selected by RSVP |
+-----------------+----------------+---------------------------------------+
For flows that may take a significant fraction of the network (i.e. For flows that may take a significant fraction of the network (i.e.
are ``special'' and can't just be lumped under a static class), we are ``special'' and can't just be lumped under a static class), we
need a more dynamic way of establishing these classifications. In need a more dynamic way of establishing these classifications. In
the short term, this applies to many multimedia calls since the the short term, this applies to many multimedia calls since the
Internet is largely under-provisioned at the time of writing. Internet is largely under-provisioned at the time of writing.
RSVP has been standardized for just this purpose. It provides flow RSVP has been standardized for just this purpose. It provides flow
identification and classification. Hosts and applications are identification and classification. Hosts and applications are
modified to speak RSVP client language, and routers speak RSVP. modified to speak RSVP client language, and routers speak RSVP.
skipping to change at page 11, line 51 skipping to change at page 12, line 12
customer to buy from their provider a profile for higher quality customer to buy from their provider a profile for higher quality
service, and the provider polices marked traffic from the site to service, and the provider polices marked traffic from the site to
ensure that the profile is not exceeded. Within a provider's ensure that the profile is not exceeded. Within a provider's
network, routers give preferential services to packets marked with network, routers give preferential services to packets marked with
the relevant type-of-service bit. Where providers peer, they arrange the relevant type-of-service bit. Where providers peer, they arrange
for an aggregate higher-quality profile to be provided, and police for an aggregate higher-quality profile to be provided, and police
each other's aggregate if it exceeds the profile. In this way, each other's aggregate if it exceeds the profile. In this way,
policing only needs to be performed at the edges to a provider's policing only needs to be performed at the edges to a provider's
network on the assumption that within the network there is sufficient network on the assumption that within the network there is sufficient
capacity to cope with the amount of higher-quality traffic that has capacity to cope with the amount of higher-quality traffic that has
been sold. been sold. The remainder of the capacity can be filled with regular
best-effort traffic.
The remainder of the capacity can be filled with regular best-effort
traffic.
One big advantage of differentiated services over reservations is One big advantage of differentiated services over reservations is
that routers do not need to keep per-flow state, or look at source that routers do not need to keep per-flow state, or look at source
and destination addresses to classify the traffic, and this means and destination addresses to classify the traffic, and this means
that routers can be considerably simpler. Another big advantage is that routers can be considerably simpler. Another big advantage is
that the billing arrangements for differentiated services are that the billing arrangements for differentiated services are
pairwise between providers at boundaries -- at no time does a pairwise between providers at boundaries -- at no time does a
customer need to negotiate a billing arrangement with each provider customer need to negotiate a billing arrangement with each provider
in the path* in the path*
skipping to change at page 12, line 32 skipping to change at page 12, line 41
comprising a conference to be carried in the same packets. In fact comprising a conference to be carried in the same packets. In fact
it simplifies receivers if different media streams are carried in it simplifies receivers if different media streams are carried in
separate flows (i.e., separate transport ports and/or separate separate flows (i.e., separate transport ports and/or separate
multicast groups). This also allows the different media to be given multicast groups). This also allows the different media to be given
different quality of service. For example, under congestion, a different quality of service. For example, under congestion, a
router might preferentially drop video packets over audio packets. router might preferentially drop video packets over audio packets.
In addition, some sites may not wish to receive all the media flows. In addition, some sites may not wish to receive all the media flows.
For example, a site with a slow access link may be able to For example, a site with a slow access link may be able to
participate in a conference using only audio and a whiteboard whereas participate in a conference using only audio and a whiteboard whereas
other sites in the same conference with more capacity may also send other sites in the same conference with more capacity may also send
and receive video. and receive video. This can be done because the video can be sent to
a different multicast group than the audio and whiteboard. This is
This can be done because the video can be sent to a different first step towards coping with heterogeneity by allowing the
multicast group than the audio and whiteboard. This is first step receivers to decide how much traffic to receive, and hence allowing a
towards coping with heterogeneity by allowing the receivers to decide conference to scale more gracefully.
how much traffic to receive, and hence allowing a conference to scale
more gracefully.
5.1. Receiver Adaptation and Synchronization 5.1. Receiver Adaptation and Synchronization
_________________________
* With reservations there may be ways to avoid this too, but
they're somewhat more difficult given the more specific nature of
a reservation.
Figure 3: Network Jitter and Packet Audio Figure 3: Network Jitter and Packet Audio
|x|
| | |
|x| |
| | |
Compression |x| v
+ Packetizer | |
+--------+ +-------+
Microphone | | 1.5 Mbit/s link | |
+-----+ A A A | |-----------------| Router|
/~\------+__| |>>> >>> >>>| |A A A A A| |
\_/------+ |A->D |20 ms Audio| |-----------------| |
+-----+Timeslices | | ---------> | |
| | +-------+
+--------+ |A|
| | |
Shared link: |x| |
Audio traffic |A| |
interspersed w |A| |
other traffic |x| |
|x| |
|x| |
Depacketizer |A| |
+ Timing recovery |A| v
+ Decompression | |
+--------+ +-------+
Speaker | | 1.5 Mbit/s link | |
|\ +-----+ A A A | |-----------------| Router|
| +---+ | |<<< <<< <<<| |A A AA A | |
| | |-----|D->A |20 ms Audio| |-----------------| |
| +---+ +-----+Timeslices | | <--------- | |
|/ | | +-------+
+--------+ | |
|X| |
|X| |
| | |
|X| v
| |
Best-effort traffic is delayed by queues in routers between the Best-effort traffic is delayed by queues in routers between the
sender and the receivers. Even reserved priority traffic may see sender and the receivers. Even reserved priority traffic may see
small transient queues in routers, and so packets comprising a flow small transient queues in routers, and so packets comprising a flow
will be delayed for different times. Such delay variance is known as will be delayed for different times. Such delay variance is known as
jitter, and is illustrated in Figure 3. jitter, and is illustrated in Figure 3.
_________________________
* With reservations there may be ways to avoid this too, but
they're somewhat more difficult given the more specific nature of
a reservation.
Real-time applications such as audio and video need to be able to Real-time applications such as audio and video need to be able to
buffer real-time data at the receiver for sufficient time to remove buffer real-time data at the receiver for sufficient time to remove
the jitter added by the network and recover the original timing the jitter added by the network and recover the original timing
relationships between the media data. In order to know how long to relationships between the media data. In order to know how long to
buffer for, each packet must carry a timestamp which gives the time buffer for, each packet must carry a timestamp which gives the time
at the sender when the data was captured. Note that for audio and at the sender when the data was captured. Note that for audio and
video data timing recovery, it is not necessary to know the absolute video data timing recovery, it is not necessary to know the absolute
time that the data was captured at the sender, only the time relative time that the data was captured at the sender, only the time relative
to the other data packets. to the other data packets.
Figure 4: Inter-media synchronization Figure 4: Inter-media synchronization
Incoming packets
---------------- +----------------+
V A V AV A --> | Host |
---------------- | Demuxing |
+----------------+
/ \
/ \
A A / A V V \ V
v v
+---------------+ +---------------+
| Depacketizer | per source | Depacketizer |
+---------------+ delay adaptation: +---------------+
v \ 45 ms 95 ms / v
+------------+ \ / +------------+
| format | \ / | format |
| conversion | +------------------+ | conversion |
+------------+ | synchronization | +------------+
| | agent | |
| +------------------+ |
| mix / \ |
v / \ v
| | / \ | |
+-----+ / \ +-----+
| | / \ | |
+-----+ / \ +-----+
| A | / 95 ms 95 ms \ | V |
+-----+ / \ +-----+
| A | <--+ +-> | V |
+-----+ /| +--------+ +-----+
| A | +---+ | |/------\| | V |
+-----+>>>>>| | | || ||<<<<<+-----+
+---+ | |\------/|
\| +--------+
As audio and video flows will receive differing jitter and possibly As audio and video flows will receive differing jitter and possibly
differing quality of service, audio and video that were grabbed at differing quality of service, audio and video that were grabbed at
the same time at the sender may not arrive at the receiver at the the same time at the sender may not arrive at the receiver at the
same time. At the receiver, each flow will need a playout buffer to same time. At the receiver, each flow will need a playout buffer to
remove network jitter. Inter-flow synchronization can be performed remove network jitter. Inter-flow synchronization can be performed
by adapting these playout buffers so that samples/frames that by adapting these playout buffers so that samples/frames that
originated at the same time are played out at the same time (see originated at the same time are played out at the same time (see
figure Figure 4). This requires that the time base of different figure Figure 4). This requires that the time base of different
flows from the same sender can be related at the receivers, e.g. by flows from the same sender can be related at the receivers, e.g. by
making available the absolute times at which each of them was making available the absolute times at which each of them was
captured. captured.
5.2. RTP 5.2. RTP
+---------------------+-----------------------+--------------------------------------+ +-------------+----------------+--------------------------------------+
|Protocol | Documentation | Purpose | |Protocol | Documentation | Purpose |
+---------------------+-----------------------+--------------------------------------+ +-------------+----------------+--------------------------------------+
|RTP,RTCP | RFC 1889 | packet format for realtime traffic | |RTP,RTCP | RFC 1889 | packet format for realtime traffic |
|RTP Profile | RFC 1890 | specific RTP profile for AV traffic | |RTP Profile | RFC 1890 | specific RTP profile for AV traffic |
|RTP Payload Formats | RFC 2032, 2035, etc | payload formats for specific codecs | |RTP Payload | RFC 2032, | payload formats for specific codecs |
+---------------------+-----------------------+--------------------------------------+ | Formats | 2035, etc | |
+-------------+----------------+--------------------------------------+
The transport protocol for real-time flows is RTP [28]. This The transport protocol for real-time flows is RTP [28]. This
provides a standard format packet header which gives media specific provides a standard format packet header which gives media specific
timestamp data, as well as payload format information and sequence timestamp data, as well as payload format information and sequence
numbering amongst other things. RTP is normally carried using UDP. numbering amongst other things. RTP is normally carried using UDP.
It does not provide or require any connection setup, nor does it It does not provide or require any connection setup, nor does it
provide any enhanced reliability over UDP. For RTP to provide a provide any enhanced reliability over UDP. For RTP to provide a
useful media flow, there must be sufficient capacity in the relevant useful media flow, there must be sufficient capacity in the relevant
traffic class to accommodate the traffic. How this capacity is traffic class to accommodate the traffic. How this capacity is
ensured is independent of RTP. ensured is independent of RTP.
skipping to change at page 14, line 50 skipping to change at page 16, line 29
coming and going all the time, they probably do not know exactly who coming and going all the time, they probably do not know exactly who
is in the room at any one moment. is in the room at any one moment.
Reception quality information is primarily intended for debugging Reception quality information is primarily intended for debugging
purposes, as debugging of IP multicast problems is a difficult task. purposes, as debugging of IP multicast problems is a difficult task.
However, it is possible to use reception quality information for rate However, it is possible to use reception quality information for rate
adaptive senders, although it is not clear whether this information adaptive senders, although it is not clear whether this information
is sufficiently timely to be able to adapt fast enough to transient is sufficiently timely to be able to adapt fast enough to transient
congestion. congestion.
5.4. Scaling Issues and Heterogeneity
The Internet is very heterogeneous, with link speeds ranging from
around 10 kbit/s up to around 10 Gbit/s, and very varied levels of
congestion. How then can a single multicast source satisfy a large
and heterogeneous set of receivers?
_________________________ _________________________
* Note that a conference policy that restricts conference mem- * Note that a conference policy that restricts conference mem-
bership can be implemented using encryption and restricted distri- bership can be implemented using encryption and restricted distri-
bution of encryption keys, of which more later. bution of encryption keys, of which more later.
5.4. Scaling Issues and Heterogeneity Figure 5: Receiver adaptation: multiple layers and multicast groups
The Internet is very heterogeneous, with link speeds ranging from
14.4 kbit/s up to 1.2 Gbit/s, and very varied levels of congestion.
How then can a single multicast source satisfy a large and
heterogeneous set of receivers?
Figure 5: Receiver adaptation using multiple layers and multiple multicast groups /~~~\ ##### 2 Mbit/s layer
| R | ===== 512 kbit/s layer
\___/ ----- 64 kbit/s layer
#
10 Mbit/s # 10 Mbit/s
link: # link
#
/~~~\ #######> +---+
| S | =======> | |
\___/ -------> +---+
\ = 1.5 Mbit/s
Source \ = link
\ = 1.5 Mbit/s
\ = link
\ +---+=========>/~~~\
| |--------->| R |
+---+ \___/
10 Mbit/s / = \
link / = \ 128 kbit/s
/ = \ link
/ = \ 10 Mbit/s
/~~~\ +---+ link /~~~\
| R | | |--------->| R |
\___/ +---+ \___/
\
\ 10 Mbit/s
\ link
\
/~~~\
| R |
\___/
In addition to each receiver performing its own adaptation to jitter, In addition to each receiver performing its own adaptation to jitter,
if the sender layers [22] its video (or audio) stream, different if the sender layers [22] its video (or audio) stream, different
receivers can choose to receive different amounts of traffic and receivers can choose to receive different amounts of traffic and
hence different qualities. To do this the sender must code they hence different qualities. To do this the sender must code they
video as a base layer (the lowest quality that might be acceptable) video as a base layer (the lowest quality that might be acceptable)
and a number of enhancement layers, each of which adds more quality and a number of enhancement layers, each of which adds more quality
at the expense of more bandwidth. With video, these additional at the expense of more bandwidth. With video, these additional
layers might increase the framerate or increase the spatial layers might increase the framerate or increase the spatial
resolution of the images or both. Each layer is sent to a different resolution of the images or both. Each layer is sent to a different
skipping to change at page 15, line 35 skipping to change at page 18, line 8
if they are going to respond to congestion in this way, then we also if they are going to respond to congestion in this way, then we also
need to arrange that the receivers in a conference behind a common need to arrange that the receivers in a conference behind a common
bottleneck tend to respond together to prevent de-synchronized bottleneck tend to respond together to prevent de-synchronized
experiments by different receivers from having the net effect that experiments by different receivers from having the net effect that
too many layers are always being drawn through a common bottleneck. too many layers are always being drawn through a common bottleneck.
RLM [21] is one way that this might be achieved, although there is RLM [21] is one way that this might be achieved, although there is
continuing research in this area. continuing research in this area.
6. Conference Control 6. Conference Control
+----------+----------------------------+-----------------------------------------------+ +---------+--------------------------+-------------------------------------+
|Protocol | Documentation | Purpose | |Protocol | Documentation | Purpose |
+----------+----------------------------+-----------------------------------------------+ +---------+--------------------------+-------------------------------------+
|H.323 | ITU recommendation H.323 | Tightly coupled conference setup and control | |H.323 | ITU recommendation H.323 | Tightly coupled conference setup |
|H.332 | ITU recommendation H.332 | Loosely couple extensions to H.323 | | | | and control |
+----------+----------------------------+-----------------------------------------------+ |H.332 | ITU recommendation H.332 | Loosely coupled extensions to H.323 |
+---------+--------------------------+-------------------------------------+
Conferences come in many shapes and sizes, but there are only really Conferences come in many shapes and sizes, but there are only really
two models for conference control: light-weight sessions and tightly two models for conference control: light-weight sessions and tightly
coupled conferencing. For both models, rendezvous mechanisms are coupled conferencing. For both models, rendezvous mechanisms are
needed. Note that the conference control model is orthogonal to needed. Note that the conference control model is orthogonal to
issues of quality of service and network resource reservation, and it issues of quality of service and network resource reservation, and it
is also orthogonal to the mechanism for discovering the conference. is also orthogonal to the mechanism for discovering the conference.
Light-weight sessions are multicast based multimedia conferences that Light-weight sessions are multicast based multimedia conferences that
lack explicit conference membership control and explicit conference lack explicit conference membership control and explicit conference
skipping to change at page 16, line 25 skipping to change at page 18, line 48
suitable for Internet use are those belonging to the ITU's H.323 suitable for Internet use are those belonging to the ITU's H.323
family [16]. However it should be noted that this is inappropriate family [16]. However it should be noted that this is inappropriate
for larger conferences where scaling problems will be introduced by for larger conferences where scaling problems will be introduced by
the conference control mechanisms. The Simple Conference Control the conference control mechanisms. The Simple Conference Control
Protocol (SCCP) [18] has been proposed as a more scalable distributed Protocol (SCCP) [18] has been proposed as a more scalable distributed
conference control protocol. conference control protocol.
In order to try and address large conferences, the ITU is currently In order to try and address large conferences, the ITU is currently
standardising H.332 [17], which is essentially a small tightly standardising H.332 [17], which is essentially a small tightly
coupled H.323 conference with a larger lightweight-sessions-style coupled H.323 conference with a larger lightweight-sessions-style
_________________________
* There is some confusion on the term session, which is some-
times used for a conference and sometimes for a single media
stream transported by RTP. In this document, we prefer to use the
less ambiguous term conference except where existing protocols use
the term session.
conference listening in as passive participants. It is not yet clear conference listening in as passive participants. It is not yet clear
whether H.332 will see large scale acceptance, as its benefits over a whether H.332 will see large scale acceptance, as its benefits over a
simple lightweight session are not terribly obvious. It seems likely simple lightweight session are not terribly obvious. It seems likely
that lightweight sessions combined with stream authentication (see that lightweight sessions combined with stream authentication (see
section 8.3) might be a more appropriate solution for many potential section 8.3) might be a more appropriate solution for many potential
customers. customers.
6.1. Controlling Multimedia Servers 6.1. Controlling Multimedia Servers
+----------+----------------+-------------------------------------------------------+ +---------+---------------+---------------------------------+
|Protocol | Documentation | Purpose | |Protocol | Documentation | Purpose |
+----------+----------------+-------------------------------------------------------+ +---------+---------------+---------------------------------+
|RTSP | RFC 2326 | Remote control and AV playback and recording servers | |RTSP | RFC 2326 | Remote control and AV playback |
+----------+----------------+-------------------------------------------------------+ | | | and recording servers |
+---------+---------------+---------------------------------+
The Real-Time Stream-control Protocol (RTSP) provides a standard way The Real-Time Stream-control Protocol (RTSP) provides a standard way
to remote control a multimedia server. While primarily aimed at web- to remote control a multimedia server. While primarily aimed at web-
based media-on-demand services, RTSP is also well suited to provide based media-on-demand services, RTSP is also well suited to provide
VCR-like controls for audio and video streams, and to provide VCR-like controls for audio and video streams, and to provide
playback and record functionality of RTP data streams. A client can playback and record functionality of RTP data streams. A client can
specify that an RTSP server plays a recorded multimedia session into specify that an RTSP server plays a recorded multimedia session into
an existing multicast-based conference, or can specify that the an existing multicast-based conference, or can specify that the
_________________________
* There is some confusion on the term session, which is some-
times used for a conference and sometimes for a single media
stream transported by RTP. In this document, we prefer to use the
less ambiguous term conference except where existing protocols use
the term session.
server should join the conference and record it. server should join the conference and record it.
6.2. Protocols for Non-A/V Applications 6.2. Protocols for Non-A/V Applications
Applications other than audio and video have evolved in Internet Applications other than audio and video have evolved in Internet
conferencing, e.g. Imm, Wb [8], NTE [11]. Such applications can be conferencing, e.g. Imm, Wb [8], NTE [11]. Such applications can be
used to substitute for meeting aids in physical conferences used to substitute for meeting aids in physical conferences
(whiteboards, projectors) or replace visual and auditory cues that (whiteboards, projectors) or replace visual and auditory cues that
are lost in teleconferences (e.g., a speaker list application); they are lost in teleconferences (e.g., a speaker list application); they
also can enable new styles of joint work. also can enable new styles of joint work.
skipping to change at page 18, line 7 skipping to change at page 20, line 31
|SDP | RFC 2327 | Session description format | |SDP | RFC 2327 | Session description format |
|SAP | Internet draft | Multicast session announcements | |SAP | Internet draft | Multicast session announcements |
+----------+------------------+----------------------------------+ +----------+------------------+----------------------------------+
The rendezvous mechanism for many light-weight sessions is a The rendezvous mechanism for many light-weight sessions is a
multicast based session directory. This ``broadcasts'' session multicast based session directory. This ``broadcasts'' session
descriptions [9] to all the potential session participants. These descriptions [9] to all the potential session participants. These
session descriptions provide an advertisement that the session will session descriptions provide an advertisement that the session will
exist, and also provide sufficient information including multicast exist, and also provide sufficient information including multicast
addresses, ports, media formats and session times so that a receiver addresses, ports, media formats and session times so that a receiver
of the session description can join the session. of the session description can join the session. The session
description protocol (SDP) describes the content and format of a
The session description protocol (SDP) describes the content and multimedia session, and the session announcement protocol (SAP) is
format of a multimedia session, and the session announcement protocol used to distribute it to all potential session recipients.
(SAP) is used to distribute it to all potential session recipients.
This mechanism can also be applied to advertised tightly coupled This mechanism can also be applied to advertised tightly coupled
sessions, and only requires that additional information about the sessions, and only requires that additional information about the
mechanism to use to join the session is given. However, as the mechanism to use to join the session is given. However, as the
number of sessions in the session directory grows, we expect that number of sessions in the session directory grows, we expect that
only larger-scale public sessions will be announced in this manner, only larger-scale public sessions will be announced in this manner,
and smaller, more private sessions will tend to use direct invitation and smaller, more private sessions will tend to use direct invitation
rather than advertisement. rather than advertisement.
7.2. Session Invitation 7.2. Session Invitation
skipping to change at page 19, line 5 skipping to change at page 21, line 30
user can be invited to participate in a conference. SIP does not user can be invited to participate in a conference. SIP does not
care whether the session is already ongoing, or is just being care whether the session is already ongoing, or is just being
created, and it doesn't care whether the conference is a small created, and it doesn't care whether the conference is a small
tightly coupled session or a huge broadcast -- it merely conveys an tightly coupled session or a huge broadcast -- it merely conveys an
invitation to a user in a timely manner, inviting them to invitation to a user in a timely manner, inviting them to
participate, and provides enough information for them to be able to participate, and provides enough information for them to be able to
know what sort of session to expect. Thus although SIP can be used know what sort of session to expect. Thus although SIP can be used
to make telephone-style calls, it is by no means restricted to that to make telephone-style calls, it is by no means restricted to that
style of conference. style of conference.
Figure 6: Joining a light-weight multimedia session
8. Security 8. Security
There is a temptation to believe that multicast is inherently less There is a temptation to believe that multicast is inherently less
private than unicast communication since the traffic visits so many private than unicast communication since the traffic visits so many
more places in the network. In fact, this is not the case except more places in the network. In fact, this is not the case except
with broadcast and prune type multicast routing protocols [4]. with broadcast and prune type multicast routing protocols [4].
However, IP multicast does make it simple for a host to anonymously However, IP multicast does make it simple for a host to anonymously
join a multicast group and receive traffic destined to that group join a multicast group and receive traffic destined to that group
without the other senders' and receivers' knowledge. If the without the other senders' and receivers' knowledge. If the
application requirement (conference policy) is to communicate between application requirement (conference policy) is to communicate between
skipping to change at page 20, line 29 skipping to change at page 23, line 4
each of the conference media streams in the session. Whilst this each of the conference media streams in the session. Whilst this
does not solve the key distribution problem, it does allow a single does not solve the key distribution problem, it does allow a single
conference to be announced more than once to more than one key-group, conference to be announced more than once to more than one key-group,
where each group holds a different session directory key, so that the where each group holds a different session directory key, so that the
two groups can be brought together into a single conference without two groups can be brought together into a single conference without
having to know each other's keys. having to know each other's keys.
8.3. Secured ``Broadcasts'' 8.3. Secured ``Broadcasts''
While private-key encryption is sufficient to exclude non-members While private-key encryption is sufficient to exclude non-members
Figure 6: Joining a light-weight multimedia session
User A | |
creates | SDP/SAP |
conference |-----------> |
| |User B
| SDP/SAP IGMP |starts
|-----------> IGMP /--<---------|session
| IGMP /-<------/ |directory
|-----------<---------/ |
| |
| SDP/SAP |
|-------------------------------------------->|
| |
User A | |
starts | RTP |
sending |===========> |
| RTCP |
|-----------> |
| |
| RTP |
|===========> |
| |
| RTP |User B
|===========> IGMP |joins
| IGMP /--<---------|conference
| IGMP /-<------/ |
|-----------<---------/ |User's App
| RTCP |Sends RTCP
| RTP /--<---------|Session
|===============================/============>|Message
|<-----------------------------/ |
| RSVP Path Message |
|-------------------------------------------->|
| |User's App
| RTP /-----------|makes
|================================/===========>|reservation
| RSVP RESV Message /-----/ |
|<-----------------------/ |
| |
| RTP |Quality
|============================================>|of Service
| |improves
from sending or receiving multicast conference traffic, it does mean from sending or receiving multicast conference traffic, it does mean
that all members of a session are equal. This is normally acceptable that all members of a session are equal. This is normally acceptable
for multi-way conferences, but will not be acceptable for many for multi-way conferences, but will not be acceptable for many
broadcasters who require the ability to ensure that only they can broadcasters who require the ability to ensure that only they can
send, perhaps in addition to ensuring that only their paid customers send, perhaps in addition to ensuring that only their paid customers
can receive. This is nicely illustrated by the multicast of the can receive. This is nicely illustrated by the multicast of the
Rolling Stones concert in 1994 which was billed as being the first Rolling Stones concert in 1994 which was billed as being the first
live concert on the Mbone. In fact, this honour goes to a little live concert on the Mbone. In fact, this honour goes to a little
known band called Severe Tire Damage who had multicast an impromptu known band called Severe Tire Damage who had multicast an impromptu
concert a year previously. To make their point, just before the concert a year previously. To make their point, just before the
skipping to change at page 22, line 30 skipping to change at page 26, line 7
10. Acknowledgments 10. Acknowledgments
Acknowledgments are due to the End-to-End Research Group, the Int- Acknowledgments are due to the End-to-End Research Group, the Int-
serv, RSVP, MMUSIC and AVT working groups of the IETF, and discussion serv, RSVP, MMUSIC and AVT working groups of the IETF, and discussion
with colleagues at UCL. The earliest clear exposition of some of the with colleagues at UCL. The earliest clear exposition of some of the
ideas here was presented at ACM SIGCOMM 1994 in London by Van ideas here was presented at ACM SIGCOMM 1994 in London by Van
Jacobson. Jacobson.
11. Authors' Addresses 11. Authors' Addresses
Mark Handley, Mark Handley
USC Information Sciences Institute, AT&T Center for Internet Research at ICSI
c/o NE43-540, MIT LCS, 1947 Center St, Suite 600
545 Technology Square, Berkeley, CA 94704
Cambridge, MA 02139, USA EMail: mjh@aciri.org
Email: mjh@isi.edu
Jon Crowcroft, Jon Crowcroft,
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street, Gower Street,
London WC1E 6BT, UK. London WC1E 6BT, UK.
Email: j.crowcroft@cs.ucl.ac.uk Email: j.crowcroft@cs.ucl.ac.uk
Carsten Bormann, Joerg Ott Carsten Bormann, Joerg Ott
Universitaet Bremen TZI Universitaet Bremen TZI
skipping to change at page 23, line 4 skipping to change at page 26, line 27
London WC1E 6BT, UK. London WC1E 6BT, UK.
Email: j.crowcroft@cs.ucl.ac.uk Email: j.crowcroft@cs.ucl.ac.uk
Carsten Bormann, Joerg Ott Carsten Bormann, Joerg Ott
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
D-28334 Bremen, GERMANY. D-28334 Bremen, GERMANY.
Email: cabo@tzi.org, jo@tzi.org Email: cabo@tzi.org, jo@tzi.org
References References
[1] A. Ballardie, P. Francis, J. Crowcroft, ``An Architecture for [1] A. Ballardie, P. Francis, J. Crowcroft, ``An Architecture for
Scalable Inter-Domain Multicast Routing'', ACM SIGCOMM 1993, pp Scalable Inter-Domain Multicast Routing'', ACM SIGCOMM 1993, pp
85-95. 85-95.
[2] C. Bormann, ``Providing integrated services over [2] C. Bormann, ``Providing integrated services over low-bitrate
low-bitrate links,'' RFC2689, September 1999. links,'' RFC2689, September 1999.
[3] CCITT (Consultative Committee on International Telegraphy and [3] CCITT (Consultative Committee on International Telegraphy and
Telephony). ``Recommendation X.509: The Directory -- Telephony). ``Recommendation X.509: The Directory --
Authentication Framework.'' 1988. Authentication Framework.'' 1988.
[4] S. Deering, C. Partridge, D. Waitzman, ``Distance Vector [4] S. Deering, C. Partridge, D. Waitzman, ``Distance Vector
Multicast Routing Protocol'', RFC 1075, Nov 1988. Multicast Routing Protocol'', RFC 1075, Nov 1988.
[5] Steve Deering, ``Multicast Routing in Internetworks and Extended [5] Steve Deering, ``Multicast Routing in Internetworks and Extended
LANs'', ACM SIGCOMM 88, August 1988, pp 55-64 and ``Host LANs'', ACM SIGCOMM 88, August 1988, pp 55-64 and ``Host
Extensions for IP Multicasting'', RFC 1112. Extensions for IP Multicasting'', RFC 1112.
[6] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C-G. Liu, L. [6] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C-G. Liu, L.
Wei ``An Architecture for Wide Area Multicast Routing'' ACM Wei ``An Architecture for Wide Area Multicast Routing'' ACM
SIGCOMM 1994, pp 126-135. SIGCOMM 1994, pp 126-135.
[7] Estrin, Farinacci, Helmy, Thaler, Deering, Handley, Jacobson, [7] Estrin, Farinacci, Helmy, Thaler, Deering, Handley, Jacobson,
Liu, Sharma, Wei, ``Protocol Independent Multicast-Sparse Mode Liu, Sharma, Wei, ``Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification'', RFC 2117. (PIM-SM): Protocol Specification'', RFC 2362.
[8] S. Floyd, V. Jacobson, S. McCanne, C-G. Liu, L. Zhang, ``A [8] S. Floyd, V. Jacobson, S. McCanne, C-G. Liu, L. Zhang, ``A
Reliable Multicast Framework for Light-weight Sessions and Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing'' ACM SIGCOMM 1995, pp 342-356. Application Level Framing'' ACM SIGCOMM 1995, pp 342-356.
[9] M. Handley, V. Jacobson ``SDP: Session Description Protocol'' [9] M. Handley, V. Jacobson, ``SDP: Session Description Protocol''
INTERNET-DRAFT, Dec 1997. INTERNET-DRAFT, Dec 1997.
[10] M. Handley, D. Thaler, D. Estrin, ``The Internet Multicast [10] M. Handley, D. Thaler, D. Estrin, ``The Internet Multicast
Address Allocation Architecture'', INTERNET-DRAFT, Dec 1997. Address Allocation Architecture'', INTERNET-DRAFT, Dec 1997.
[11] M. Handley, J. Crowcroft, ``Network Text Editor (NTE): A [11] M. Handley, J. Crowcroft, ``Network Text Editor (NTE): A
scalable shared text editor for the MBone'', ACM SIGCOMM 1997. scalable shared text editor for the MBone'', ACM SIGCOMM 1997.
[12] V. Hardman, A. Sasse, M. Handley, A. Watson, ``Reliable [12] V. Hardman, A. Sasse, M. Handley, A. Watson, ``Reliable Audio
Audio for Use over the Internet'' Proc INET '95, Hawaii, for Use over the Internet'' Proc INET '95, Hawaii, Internet
Internet Society, Reston, VA, 1995. Society, Reston, VA, 1995.
[13] IRTF Research Group on Reliable Multicast, [13] IRTF Research Group on Reliable Multicast,
http://www.east.isi.edu/RMRG/ http://www.east.isi.edu/RMRG/
[14] ITU ``Recommendation H.320: Narrow-band visual telephone systems [14] ITU ``Recommendation H.320: Narrow-band visual telephone systems
and terminal equipment'', ITU, Geneva, 1997 and terminal equipment'', ITU, Geneva, 1997
[15] ITU ``Recommendation T.124 -- Generic Conference Control'', ITU, [15] ITU ``Recommendation T.124 -- Generic Conference Control'', ITU,
Geneva. Geneva.
[16] ITU ``Recommendation H.323: Visual telephone systems and [16] ITU ``Recommendation H.323: Visual telephone systems and
equipment for local area networks which provide a non guaranteed equipment for local area networks which provide a non guaranteed
quality of service'', ITU, Geneva, 1996 quality of service'', ITU, Geneva, 1996
[17] ITU ``Recommendation H.332: H.323 Extended for Loosely-Coupled [17] ITU ``Recommendation H.332: H.323 Extended for Loosely-Coupled
conferences'', ITU, Geneva conferences'', ITU, Geneva
[18] C. Bormann, J. Ott, C. Reichert, ``Simple Conference Control [18] C. Bormann, J. Ott, C. Reichert, ``Simple Conference Control
Protocol'' INTERNET-DRAFT, June 1996. Protocol'' INTERNET-DRAFT, June 1996.
[19] V. Jacobson ``Congestion Avoidance and Control'', ACM SIGCOMM [19] V. Jacobson, ``Congestion Avoidance and Control'', ACM SIGCOMM
1988. 1988.
[20] J. Linn, ``Privacy Enhancement for Internet Electronic Mail: [20] J. Linn, ``Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures'', RFC Part I: Message Encryption and Authentication Procedures'', RFC
1421, Feb 1993 1421, Feb 1993
[21] S. McCanne, V. Jacobson and M. Vetterli, ``Receiver-driven [21] S. McCanne, V. Jacobson and M. Vetterli, ``Receiver-driven
Layered Multicast''. ACM SIGCOMM 1996, pp. 117-130. Layered Multicast''. ACM SIGCOMM 1996, pp. 117-130.
[22] S. McCanne, M. Vetterli, ``Joint Source/Channel Coding for [22] S. McCanne, M. Vetterli, ``Joint Source/Channel Coding for
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/