--------------12AF22201B60
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
http://www.nac.gmu.edu/ietf-dis/0087.html
--------------12AF22201B60
Content-Type: text/plain; charset=us-ascii; name="0087.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="0087.html"
another DIS transport protocol...
Jon Crowcroft (J.Crowcroft@cs.ucl.ac.uk)
Thu, 27 Jun 1996 17:22:34 +0100
* Messages sorted by: [ date ][ thread ][ subject ][ author ]
* Next message: Peter Parnes: "Re: another DIS transport protocol..."
* Previous message: Michael Myjak: "Re: PlayDay June 28, 1996"
* Next in thread: Peter Parnes: "Re: another DIS transport protocol..."
with diagrams, at
ftp://cs.ucl.ac.uk/darpa/dvr.ps
text below
jon
---------------------------------------------------->
Jon Crowcroft
Mark Handley
University College London
10 Apr 1996
This paper is about the design and implemenation of a protocol to
support scalable distributed multiparty virtual reality systems. The
paper covers the service requirements for the protocol,
the range of protocol semantics, and the congestion avoidance scheme
proposed for use with such systems. The goal is to show how multicast
can be used in a variety of ways to construct a novel system that can
admit very large numbers of simulataneous participants in an
heterogeneous network.
abstract
Introduction
Distributed VR is a relatively new area of research. Virtual reality
systems are now largely software components, rather than requiring the
dedicated head-up-display input controllers and renderer hardware of
the past. Current high-end workstations can now render scenes
described in VRML and other languages in near real time.
The introduction of audio and video input and
output on desktop machines led to the deployment of software based
multimedia conferencing, we expect to see the deployment of multi-user
virtual environments over the Internet shortly.
In this paper, we present an architecture for distributed virtual
reality. We outline the necessary network support and a transport
protocol, and the way that distributed virtual reality applications
would interact (the API if you like) with each other using these
mechanisms.
It is a goal of the architecture to provide policy free mechanisms for
distributed VR application builders. It is not a goal to make it easy
to program such applications, since it is all too easy in providing
easy-to-program distributed system tools that let the application
builder overload the network, and at the same time provide suboptimal
performance for the user.
The architecture provides necessary and sufficient hooks only for
distributed VR.
Related Work
Multicast routing is a mature area of research in the Internet. The
system that we now call the ``Mbone'' mac:94 has its roots in the
research by Cheriton and Deering where they developed the Internet
multicast model, including the idea of host groups igmp and the
basic service model for IP multicast deer:88 . It is now widely
deployed in the network, and available in most common host operating
systems and routers.
Some functions in a distributed system can best be performed in
intermediate nodes or routers, whilst others can best
be performed in end systems or hosts.
The end to end principle end2end is used to select
where to place a function.
The principle is that a function that requires end system knowledge to
carry out correctly should only exist in the end systems; where it
appears in the network, it should only be as a performance
enhancement.
Two principles behind the design of high performance, low cost
protocols that have proved themselves in this environment are
Application Layer Framing (ALF) and Integrated Layer
Processing (ILP) ddc:91 . These state simply that: the unit of
synchronisation and recovery should as far as possible be the same as
the unit of communication (packet); and that where possible, modular
functionality that is specified in layered form should not be
implemented as such, and that new designs communications systems
should factor this in so that processing associated with layered
modules can be integrated in one pass.
Combining these principles with the use of multicast for many-to-many
communication, a number of further techniques have arisen for protocol
design:
Multicasting everything is a good idea. In applications with
relatively high packet rates, the use of multicast for control
information as well as for user data is not a high load, and can
greatly simplify convergence of protocols for correctness, as well as
performance and synchronisation.
As error rates in modern networks have decreased, end to end recovery
from packet loss or re-ordering has been seen to be a more optimal
design than hop-by-hop recovery. As we move from one-to-one, through
one-to-many and on to many-to-many applications, we can see that the
same principle has to be changed. Neither the original sender
nor the network can deal with the task of delivering packets in order,
and senders cannot know when (or which) receivers are missing packets.
It is not a good idea to use a positive-acknowledgement plus
timeout-retransmission scheme for multicast applications because of
the well known ``implosion'' problem (congestive collapse caused by
multiple acknowledgements returning to the sender or
senders) CrPa88 .
Scalable reliable multicast van:95 is a technique that has seen
wide deployment in LBL's whiteboard application (the so-called ``wb'').
Wb uses the principles above to provide a reliable delivery. The
protocol and repair algorithm are briefly as follows (paraphrased
from rtpsrm ):
Messages are sent with a sequence number plus a timestamp.
There are three basic types of messages: data messages, negative
acknowledgements and heartbeat messages.
All participants keep state
for all other participants, which includes the following:
Source address, plus last seen in order sequence number
The estimated distance (delay) from this participant to each of the others.
enumerate
In addition, participants keep a number of the most recently received
messages available. This may in fact be a feature of the way
that the application is structured in any case. For example, if the
application state is the same as the effect of the
sequence of messages (as is the case with a whiteboard), then it may
be possible to cast a repair in terms of application state - i.e. to
reconstruct a message that has the same effect as the missing one.
On detecting a missing packet from a gap in the sequence number space
(between last received in order and newly received packet), a receiver
prepares to send (multicast) a negative acknowledgement, which acts as
a request for a repair from any other participant. However, the
receiver defers from sending the negative acknowledgement for a time.
This time is set so as to cause the set of potential participants
sending a negative to (implicitly) conspire so that usually only one
(or a small number) of them make the request. To do this, the timer is
drawn from a uniform distribution over the range
[c1*dsa, (c1+c2)*dsa] , where c1 and c2 are constants and da
is the requesting participant's estimate of the delay to the source.
This time is subject to a binary exponential backoff in the usual
manner if there is no response.
Participants that receive the request for repair, and wish to try and
honour it also dally before sending the repair. Their hiatus is drawn
from the distribution [d1*dab, (d1+d2)*dab] , to ensure that it
is likely that only one (or at least only a few) send the repair.
Repair request messages suppress repair requests from other sites
missing the same packet. Repair responses suppress other responses (as
well as hopefully satisfying the request!).
Finally, the delay estimation is based on the same algorithm used in
NTP ntp . Heartbeat messages are sent by each participant carrying
a list of other participants, together with the timestamp from the last
message seen from each participant t1, and the difference, d, t3-t2,
between its arrival time, t2 and the heartbeat send time t3. On
receiving a heartbeat message at t4, the delay can be estimated as
(t4 - t1 - d)/2 . This can be calculated using a rolling average,
and the mean difference kept for safety if required. (So long as paths
are reasonably symmetric, and clock rates not too different, this
gives suffices for the repair algorithm above).
Some applications require packets to have a particular inter-arrival
rate. So long as the network can support the average rate (i.e. there
is no long term congestion), ``Receiver makes good'' is generally
a low cost solution to dealing with jitter or partial packet
re-ordering. It is hard to provide a globally transmission clock in
large heterogeneous networks. Essentially, if
timestamped, and a receiver clock does not drift or wander w.r.t a
sender clock too quickly, a receiver can run an adaptive playout buffer
to restore the playout times of packets. The size of the playout
buffer is essentially twice the inter-arrival variation, to ensure a
significant percentage of packets arrive within the worst case time. A
rolling average of the inter-arrival times (kept in any case if the
algorithm described above is in use). If the mean delay varies (due to
increased or decreased load on the network, or due to route changes)
then quiet times can be used to make adjustments.
Cheriton cher:95 describes a a scheme called log based receiver repair
which was devised for distributed simulations in the DIS (the DSINet
is an ARPA funded program of work whose target is the development of a
suite of systems to support the Synthetic Theatre of War demonstration
in 1997. from which much of this research stems).
This is similar in spirit to the SRM approach, but has separate log
servers rather than expecting all applications to participate in the
repair algorithm. The upside of this is that a larger history may be
kept (and for applications where the entire history is necessary to
reconstruct current state, it may be too costly to distribute to all
sites). The downside is that a distinguished server type needs
a distinguished protocol to maintain replicant servers and so forth.
Synchronisation of messages from different sources is generally a bad
thing. van:94 Open loop protocols such as the types we have
described above (and many other heartbeat style protocols such as
routing update and reachability protocols) are prone to synchronise
send times. This can be avoided by careful selection of randomising
timers based on unique participant data (own address is a good
example).
Multicast applications cannot use positive feedback for reliability.
Nor can they use positive explicit feedback for congestion or flow
control. Instead, implicit, and aggregated information may be more
effective. One scheme for congestion Control and multicast is
described by Wakeman et al ian:94 . It is important to be
flexible. Depending on whether group communication can proceed at the
speed of the slowest participant (or link to them) or
the average, or be completely heterogeneous, we need different
schemes for flow and congestion control. We can separate these also in
to sender and receiver based adaption, and the next item refers to
work in this area. In Wakeman's scheme, the sender elicits responses
fro ma receiver set at a given distance by multicasting out a
packet with a sliding key, which essentially acts as a selector key to
choose some small percentage of recipients to act as samples to report
on traffic conditions seen at their point in the network w.r.t the
sender.
In the LBL work, this idea is generalized:
Multicast receivers keep state about all senders. As with SRM,
periodically, they
send heartbeat messages, which contain this state (perhaps spreading
the state over a set of heartbeat messages to keep the size of the
updates small. This state can be used by senders to estimate the conditions
at all points in the network. To keep heartbeat/session traffic to a
reasonable level, the rate of the beat is reduced in proportion to the
number of participants. Although this means that the rate of samples
from any given system is decreased for a larger group, the number of
samples stays the same. In fact, as a group gets larger, it is
statistically reasonable to assume that it is more evenly and widely
distributed, and may give better and better samples concerning
traffic conditions throughout the multicast distribution fabric.
McCanne, on his work on multicast video, has looked at
layered media encodings, and how they may be mapped onto
multiple groups. mccanne:96
In this work, different levels of quality (or urgency, or interest)
are sent to different group addresses. The number of levels, and
amount that is sent in each can be adjusted using schemes such as the
one described just before. However, receivers can independently adjust
the rate of traffic that arrives at them simply by joining (to increase)
or leaving (to decrease) one of more groups, corresponding to the
appropriate coding levels.
Flow and Congestion Signal actions are generally the same for
multicast applications as for unicast. The stable, and safe algorithm
used in TCP since 1988 van:88 , with a slow start cycle, a congestion
control
cycle with exponential backoff and linear increase, and a fast
retransmit cycle to avoid short lived congestion can be employed.
itemize
The rest of this paper is structured as follows:
In the next section, we outline the structure of a distributed virtual
reality system. After that we look at some of the real requirements
from distributed VR, both from systems and the human perspective.
Following that we present the transport protocol.
Finally we look at further work that needs to be done.
General Idea and Problems
Virtual Reality systems are really glorified renderers combined with
simulations, and some fancy display and pointer technology.
The software components typically include the roughly what you would
expect, as illustrated in figure fn:vrpic .
[htb]
figure=vrpic.ps
.05in
fn:vrpic Virtual Reality Software Structure
figure
The performance requirements for distributing VR are surprising. Once
a system is up and running, it transpires that objects are
introduced/created and destroyed, with relatively low frequency. If a
distributed VR system runs the collision detection and rendering at
all receivers, it is only POV and object locations and attitudes that need
updating. Here, though, there may be an extremely stringent latency
requirement because of multiple interactions with other objects.
We need three main components to a protocol
to distribute this functionality:
A Virtual World bulk load protocol
An object naming system
An update protocol
enumerate
The virtual world bulk load protocol could be based in a number of
existing protocols for large scale informationn dissemaintation. We
assume that virtual worlds are potentially very large databases
(although many VRML examples are not that large, we would anticipate
this changing as time progresses and people develop a richer taste in
virtual environments). However, it may be possible to use the update
protocol that we are devising here too, if it is engineered for high
throughput as well as low latency.
The object naming system requires hierarchical naming and wildcarding,
as well as a clean mapping from object to multicast group. Such a
system has been devised in earlier work, and is partially implemented
in the CCCP system cccp .
The update protocol is what we will concentrate on here. Essentially,
we propose an extension of SRM, together with the congestion avoidance
mechanisms taken from Wakeman and McCanne's work. We propose
basing the protocol on RTP, as is described in Parnes'
work rtpsrm , since it is likely that eventually VR worlds may
include media such as audio and video, and we see no reason to use a
different packet header to support point of view and object motion,
and new object upload.
We propose that the constants of repair can be adjusted in favour of
fast recovery rather than low numbers of repeated requests and repairs,
since the load caused by this (given the size of repairs) is relatively
small.
The sender application needs to specify the semantics of the
operation, and this is conveyed in single field in the protocol
so that receivers can work out whether a repair request is
relevant or whether a new update will overwrite the effect anyhow.
[htb]
figure=dvrmp.ps
.05in
fn:dvrmp The Distributed Virtual Reality Multicast Protocol Stack
figure
Virtual Reality Operations, User Views and Networ Considerations
For a distributerd multi-party application, there are a number
of constraints which we might try to satisfy.
Convergence, or does the interface show a system that
reaches eventual consistency.
Determinism, or does the system behave according to users'
expectations of the underlying model.
Multiple Modifiers - does the system allow more than a single user to
modify an object (write/update state associated with an object).
Interactivity - does the system let users lock an object so that they
then have exclusive write/update access.
itemize
A key point in the
design of the system is that when operating over a network with loss,
reordering, and different levels of throughput/latency between
different senders and recipients, it is clear that it is
impossible to satisfy all four of these at any one time.
It should be sufficient to relax one of the constraints at one
time, but it will dependent on a particular application and user
requirements which, constraint is the appropriate one to relax.
Network conditions that pertain to erach of these contraints are:
Capacity - bits per second - may differ between a sender and a set of
recipients - a distribution tree rooted at each sender will have paths
to recipients, and different parts of the sub tree may have different
capacity.
Errors/Loss - packet loss may be due to noise on the line, transient
outage, or temporary congestion. Again, in a multi-party application,
this may be different for different receivers.
Availability - networks can partition. Some senders or recipients
may crash, or reboot at different times during a multi-party session.
Delay - delays over long-haul networks and is it really worth
video conferencing with your next door neighbour? , even without
queues, can be significant. Again, they will usually differ from one
recipient to the next.
itemize
Application Model
Initially, we are making the big assumption here, that the model
run at each site/host is the same, and that the only differences are POVs
and the user at each host. However, it is not necessary for all users
at all sites to ``see'' all objects. In fact, real estate probably
precludes this. This means that certain (large) optimisations are
possible in terms of delivering operation/messages to each host.
The set of typical operations between a VR application and the
underlying system range from moving point of view to moving objects
themselves and altering the attitudes.
A more advanced approach, one could consider sending trajectories
around, and having receivers apply the model world to the object. (eg.
gravity, wind, friction, etc etc).
Messages may be idempotent (describe an absolute position for an
object, or position and velocity, and so on), or not (maybe they just
say how far the object has moved).
Interactions between users of a distributed VR application are
complex. An object must in some senses have an "owner". This may be
the user at a site (e.g. if the object is the POV itself, or the
glove/pointer, etc), or an object currently under the control of a
user.
Thus we should associate a set of objects (and users) with a portion of the
multicast address space - the idea is that a user is in some
locale and that only operations relative to that locale need be
delivered to their system.
Furthermore, there most be some notion of ``real'' virtual world
distance. The set of objects in VR in a locale that are ``near'' a user
are subject to interactions which can reasonably be modelled without
having to worry about propagation delay across the net. Beyond some
distance, and the time to get a message fro mthe originator of the
action to the hosts that a set of POVs that include this locale may
simply be too high to consider. For example, imagine playing catch
in a virtual world simulated between two machines on the net. The time
for the ball to reach the ground is less than the time for the message
to cross a terrestrial line more than a few thousand miles.
However, it may be possible to introduce some element of representation
of distance into the user interface - two approaches suggest
themselves based on physics models of the real world:
Uncertainty - as an object gets further away, we can introduce less
certainty about its position (note that the SRM protocol above gives
us enough information to do this accurately!).
Relativity - we could warp spacetime in the virtual environment to produce
a similar effect to gravity - action at a distance could become much
slower.
enumerate
Given this, different VR applications may need to relax a
different one of the four constraints, possibly at different times.
In fact, we can envisage single applications that need to relax
different constraints for different objects at different times.
The Distributed Virtual Reality Multicast Protocol, DVRMP
DVRMP runs on top of RTP rtp and UDP. All DVRMP messages are multicast.
As in Parnes' proposal, we use RTP data packets as is, for data. If
reliability is needed, the RTP PT field is used to indicate SRM,
otherwise it simply conveys normal data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
verbatim
The SSRC is the source VR application. the CSRC can be used for input
from specific devices.
We use RTCP as is for session quality reports, and respect the PARNES
protocol for reliability:
SRM RTCP Packet:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|CM | Count | PT=SRM=205 | length | header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Hearbeats (CM = 0)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | Not Used |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
NACKs/Repair Requests (CM = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Followed by
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC 1
|block1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last time-stamp(LTQ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLTQ |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC 2
|block2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
verbatim
More than one multicast group is used. Session messages are used
within one multicast group to advertise the existence of participants and
objects. Objects have owners. At any one time, the owner is the source
of the session messages about an object.
Messages can be marked as reliable or not reliable, however, this is
not binding on recipients. Recipients can operate the repair algorithm
on reliable object messages in the normal way. Other messages are
deemed ephemeral, and can be lost (or discarded) at will this
limits the amount of storage necessary for receivers participating in a
possible repair. It is derived fro mthe fact that there are many kinds
of ways to send descriptions of object locations, velocity, trajectory.
Some are coded so that loss of a single message makes it hard to
recover, whilst others are largely simply lists of deltas, and
recovery may be reasonably easy, whilst others are explicit
coordinates, and only the latest message is relevant. .
Congestion
A key question about reliable (and non-reliable, e.g. video/audio)
multicast traffic is that of congestion control. Unicast applications
are typically subject to congestion avoidance or control schems such
as the Van Jacobson/cite van:88 scheme in TCP, or more explicit mechanisms
such as
are employed by DECNET'S TP4 transport using the ``congestion
experienced'' bit in the network level header to convey problems. A
Native ATM stack might be designed to do something similar with the
ABR service RM cell explicit rate indication.
However, multicast cannot scale to even modest numbers of receivers
with such schemes. Wakeman wake proposed a mechanism for
adaptive video sources. McCanne mccanne:96 proposes a receiver driven
mechanism for layered coded video or other media.
Virtual Reality sources (as with all such ALF style applications)
should be at liberty to use the congestion signal, depending on the
application.
But the question is still one of, given a signal, what action should
be taken? There are two places to consider:
Intra-tree congestion
Inter-tree congestion
enumerate
Given a distrution tree from a source, it is possible that one or more
links on the tree may become congested. The descision must be made
whether to accondate the slowest (lowest common denominator) link, or
to split of levels of coding, or to compromise. A scheme should also
be safe and stable. Both Wakeman and McCanne's schemes are
applicable.
Given multiple sources competing for a link that happens to be shared
between two (or more) distribution trees,
TCP is known to be appropximately fair (over time, and allowing for
the deifference in delay between a shared bottleneck and seperate
sources), which could be normalized for.
However, let's consider a distributon tree with N recipieients from
two sources, S1 and S2. Now if S1 is a TCP source, it will generate Order
N * ln(N) (actually log base degree of the tree, G) link's worth of
traffic, whilst the multicast source S2 would generate Order G*N.
Should the multicast source get 1 mth share on the overloaded link, or
50 ? Clearly, the latter is a more reasonable answer. Yet how to
provide a feedback scheme that has this effect? and further, how to
devise such a scheme so that it is normalized to the receiver set
size, and to the delays from source to bottleneck?
All grist for future research!
Group Dynmamics
VR needs low latency. It may have large nukbers of recipienets. Thios
seems to imply some form of source based, dense mode, distribution
tree. On the opther hand, the locus of interest may be both small, and
sparse, and fast changing. This seems, by contrast to imply that a
sparse mode tree is needed.
It is clear that more study us needed on Distributed VR using
prototypes to see what exactly are the group dynamics that merge from
typical applications. However, I think it is clear that we will need a
hierarchical address space, with a two level allocation scheme, one
level operating relatively slowly to form distribution trees, and the
second i nthe manner of RSVP dynamic filters, to rapidly enable and
disable paths to receivers as they wish to turn on and off the flow of
data. This is not quite so ciritical as the ``fast leavele''
requirement for high resolution video, sonce the data rates are quite
modest, but given the number of potneital sources, the aggregate data
rate within the network could become large if we do not have efficient
ways of suppressing unwanted feeds.
Prototype Code/Performance
Further Work
Some performance analysis of the use of SRM for low latency repair is
needed.
Acknowledgements
Thanks for Mel Slater and folks at Division for discussions.
99
igmp IGMP
Steve Deering
Multicast Routing in Internetworks and Extended LANs, ACM SIGCOMM 88,
August 1988, pp 55-64
and Host Extensions for IP Multicasting, RFC 1112
deer:88 S.Deering and D.Cheriton. ``Multicast routing in datagram
internetworks and extended LANs.'' ACM Transactions on Computer Systems,
pages 85--111, May 1990.
dvmrp DVMRP
RFC 1075 S. Deering, C. Partridge, D. Waitzman, "Distance Vector
Multicast Routing Protocol", 11/01/1988.
van:95 S. Floyd, V. Jacobson, S. McCanne, C-G. Liu, L. Zhang,
``A Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing'', Proc ACM SIGCOMM 1995, Cambridge, Mass.
ian:94 J. Bolot, I.Wakeman, T.Turletti, ``Scalable feedback
control for multicast video distribution in the Internet'', Proc ACM
SIGCOMM 1994, London,UK
ddc:91 D.D. Clark, D.L. Tennenhouse, ``Architectural
Considerations for a New Generation of Protocols'', Proc ACM SIGCOMM
1990, Philadelphia, Pennsylvania
mac:94 M.R. Macedonia, , D.P. Brutzman, ``Mbone Provides
Audio and Video Across the Internet'', IEEE Computer, Vol.27 No.4, April
1994, pp. 30-36.
rtp RTP
H. Schulzrinne, S.Casner, R.Frederick and V.Jacobson
RTP: A Transport Protocol for Real-Time Applications
Internet Draft draft-ietf-avt-rtp-07.txt, Work In Progress, Late
1995.
end2end E2E
J.Saltzer, D.Reed, D.Clark
``End-to-End Arguments in System Design''
ACM Transactions on Computer Systems, 2, 4, pp 277-288
November 1984
cher:95 LOG
H.Holbrook, S.Singhal and D.Cheriton
``Log-Based Receiver-Reliable Multicast for Distributed Interactive
Simulation''
ACM SIGCOMM 1995
Vol 25, No. 4, pages 328-341
van:94 SYNC
``On the Synchronisation of Periodic Routing Messages''
Proc ACM SIGCOMM, 93
San Francisco 1993.
mccanne:96 RLM
``Receiver-driven Layered Multicast'',
S. McCanne, V. Jacobson, and M. Vetterli,
(Univ. of California, Berkeley and Lawrence Berkeley National
Laboratory)
ACM SIGCOMM, Stanford, Cal, August 1996
CrPa88 MTP
Crowcroft, J., Paliwoda, K,
``A Multicast Transport Protocol''
Proceedings of the ACM SIGCOMM 88 Symposium
rtpsrm RTPSRM
Peter Parnes, LuTH/CDT
``RTP extension for Scalable Reliable Multicast''
draft-parnes-avt-srm-00.txt, Work in Progress.
ntp NTP
David Mills,
``Improved Algorithms for Synchronising Computer Network Clocks,
Proceedings of SIGCOMM 94, London
Vol 24, No. 4 pp 317-327
vrml VRML
Those nice vrml people at SDSC
cccp CCCP
M.Handley, I. Wakeman, J.Crowcroft
The Conference Control Channel Protocol
Proc of ACM SIGCOMM 95
Vol 25, No. 4, pp 275-287
van:88 TCP
Van Jacobson
Congestion Avoidance and Control
Vol 18, No. 4, pages 314-329,
ACM SIGCOMM 1988, Stanford, USA
wake WAKE
Jean Bolot, Thierry Turletti, Ian Wakeman
Scalable Feedback Control for Multicast Video Distribution in the Internet
Vol 24, No. 4, pp 58-67
ACM SIGCOMM 1994, London 1994
thebibliography
document
* Next message: Peter Parnes: "Re: another DIS transport protocol..."
* Previous message: Michael Myjak: "Re: PlayDay June 28, 1996"
* Next in thread: Peter Parnes: "Re: another DIS transport protocol..."
--------------12AF22201B60--