An Efficient Hybrid Multicast Transport Protocol for Collaborative

Virtual Environment with Networked Haptic

A::eaine Boukerche and Haifa Maamar
PARADISE Research Laboratory
SITE, University oI Ottawa

Abstract

In recent years, we have witnessea a growing interest in synchronous collaboration basea class of
applications. Several techniques for Collaborative Jirtual Environments CJE, Haptic, Auaio ana Jisual
Environments C-HAJE were aesignea. However several challenging issues remain to be resolvea before
CJE ana C-HAJE become a common place. In this paper, we focus upon applications that are basea on
closely couplea ana highly synchroni:ea haptic tasks that require a high- level of cooraination among the
participants. Four main protocols were aesignea to resolve the synchroni:ation issues in such
environments. the Synchronous Collaboration Transport Protocol (SCTP), the Selective Reliable
Transmission Protocol (SRTP), the Reliable Multicast Transport Protocol (RMTP) ana the Scalable
Reliable Multicast (SRM). While these four protocols have shown gooa performance for CJE ana C-
HAJE class of applications, none of these protocols was able to meet all the of the basic CJE requirement
i.e., scalability, reliability, synchroni:ation ana minimum aelay s. In this paper, we present a hybria
protocol that is able to satisfy all the CJE ana C-HAJE requirements ana aiscuss its implementation.

1. INTRODUCTION
Nowadays, virtual environments are used in many
scenarios such as tele-surgery, military training,
gaming, industrial training, etc |8,9,17,20|. All these
applications require that the users collaborate in
closely coupled and highly synchronized tasks to
manipulate shared objects. By adding the notion oI
'Haptic to the CVE, the degree oI synchronization
became higher |17| and the design oI a protocol that
satisIies the CVE requirements and that ensure an
eIIicient communication, became urgent. One main
issue that the CVE applications encounter is the lack
oI synchronization due to the packet delay, loss and
jitter |17|. In Iact, due to the network limitation and
the traIIic conditions, some oI the packets sent are
lost or delayed and this lead to a lack oI
synchronization among users. Several researches
were completed, and many strategies were designed
in order to avoid this problem. But all proposed
protocols Iailed to resolve the synchronization issue
and satisIy all the CVE requirements: reliability,
minimum delay, scalability and synchronization.
Every time a protocol is designed, it concentrates
only in one aspect and Iails to meet the other
requirements necessary Ior the CVE and C-HAVE
applications. Moreover, most oI the protocols
designed didn`t satisIy the end-to-end delay, deIined
by the collaboration environments |8, 9|, which can
not

This work is partially supported by ORNEC and NSERC.
exceed the 200 msec. Among the protocols designed
in this area, we mention SRTP, SRM, RMTP and
SCTP. In our work, we propose a hybrid protocol
that combines these Iour protocols mentioned beIore
and takes advantages oI the Ieatures oI everyone.
This protocol has a multicast tree architecture to
avoid the congestion and delay problems and uses
three modes oI transmission to ensure the transport
oI the data reliably. Our main contributions, added to
the combination oI the protocols, is to add a timer
that allows the receivers to detect a loss or a delayed
packet.

2. PREVIOUS WORK
Several research eIIorts were done in order to design
a protocol that satisIies the requirements oI the CVE
and C-HAVE: reliability, minimum delay,
scalability, and synchronization. Numerous protocols
were proposed and used in the CVE and C-HAVE
applications. These protocols can be classiIied into
three categories: protocols dealing with the
networking problems, those that have a Human-
Computer Interaction and protocols that use
predictive techniques |17|. In this paper, we are
going to Iocus more on the Iirst category. For
networking related problems, many protocols were
designed in order to solve the network problems such
as the packet delay, loss and the jitter. Selective
Reliable Transmission Protocol (SRTP) is especially
eIIicient in its transmission modes that allowed it to
meet the communication requirements |1,2,3,4|.
However, it doesn`t address the synchronous
collaboration issue |9|. A second protocol designed
HAVE'2006 - International Workshop on
Haptic Audio Visual Environments and their Applications
Ottawa, Canada 4-5 November 2006
78 1-4244-0761-3/06/$20.002006IEEE

in the same category is Reliable Multicast Transport
Protocol (RMTP) that was especially known Ior its
perIormance in ensuring a reliable transport |7|. It is
designed in a hierarchical structure in which
receivers are grouped into local regions and one oI
them is designed to be the Designated Receiver DR
who is responsible oI the local retransmission |7,14|.
The main issue oI RMTP is that it does not guarantee
ordering. Synchronous Collaboration Transport
Protocol (SCTP) is also included in the networking
problems related category. This protocol is based on
the notion oI 'Interaction Stream |8,9| and ensures
the synchroni:ation ana the timely reliability
requirements by the use oI the key-update messages
|8|. But SCTP is susceptible to jitter and also doesn`t
perIorm well Ior cascading packet loss |17|.
Smoothea SCTP was designed, later, in order to
overcome the jitter problem that SCTP encounters.
In this protocol, the packet Iormat was changed and a
timestamp was added, to make the jitter smoothed
|18|. Smoothed SCTP Iixed the jitter problem but
could not deal with lost update messages or update
messages which are delayed longer than the buIIer`s
length oI time |17|. ThereIore, Scalable Reliable
Multicast (SRM) was introduced and deigned to
solve the networking related problems. SRM was
known Ior its ability to be scalable |14|. This
protocol is designed to meet only the minimal
deIinition oI reliable multicast and does not Iorce
any particular ordering |10|. One oI the signiIicant
obstacles oI this protocol is its delay Ior the
transmission oI data.
From a Human-Computer Interaction perspective,
visual ornaments were designed in order to visualize
the network state. They are used in the representation
oI an object in order to reveal the network lag to the
users |19|, so they can be aware oI the network
discrepancies. These visual ornaments were
Decorators used to present visual Ieedback about the
network conditions |17,18,19|.
In terms oI predictive techniques, an updated
version oI the decorator technique was designed
|17|. In conjunction with both a decorator and a
networking-level solution, a prediction technique
was added.
All these protocols and techniques described
above were designed in order to provide good
collaboration Ior CVE and C-HAVE applications.
But no one was able to meet all the requirements oI
the CVE: scalability, reliability, synchronization and
minimum delay. In order to satisIy all the
requirements, a hybrid solution is chosen. This new
proposed protocol is the combination oI Iour
protocols Irom the ones previously mentioned: SRM,
SRTP, RMTP and SCTP. The objective oI our work
is to solve the networking problems and satisIy the
CVE requirements. The Iollowing; Section 3; gives a
detailed description oI the SRM, SRTP, RMTP and
SCTP protocols highlighting their advantages and
drawbacks.
3. DESCRIPTION OF THE MULTICAST
BeIore, we proceed Iurther, we wish to discuss
brieIly the Iour multicasting protocols, i.e., SRTP,
RMTP, SRM and SCTP we have used in our
proposed hybrid scheme. This section is devoted to
give a detailed description oI each protocol and
brieIly mention the problems they encountered.

3.1. SRTP. Selective Reliable Transmission
Protocol
This protocol was designed to support large scale
Distributed Interactive Simulations DIS. SRTP has
been successIully used in the Run Time
InIrastructure (RTI) / High Level Architecture
(HLA) to provide eIIicient real-time networking Ior
distributed simulation |2|. SRTP also reduces the
network capacity requirements by transmitting only
those data elements, such as position, that change
Irequently, by using real-time best-eIIort multicast
|2|. For the data that change rarely; or not at all;
SRTP transmits them reliably one time.
Depending on the kind oI data delivered SRTP has
the Iollowing three (3) modes oI operations:
(i) 0RGH ]HUR: Ior transient data that change
Irequently, such as position. This kind oI data does
not require reliability |1,2,3,4|. For the mode 0,
SRTP uses a multicast architecture that operates as
pure best-eIIort services.
(ii)0RGHRQH. Ior data that must be received reliably
by all members who are in the same multicast group.
This data can be a reIerence data in an object state
protocol. For this mode, SRTP uses a NACK-based
reliable approach, with a 'NACK suppression
mechanism as an eIIort to avoid the NACK
implosion problem.
(iii) 0RGH WZR: Ior a transaction with a single
determined receiver in the multicast group |1,2,3,4|.
For this mode, SRTP ensures a reliable and timely
transport. It uses a positive acknowledgement Ior
data that must be received reliably by a single known
member in the group.
By using these 3 modes, SRTP reduces the
network traIIic |1|. In order to keep the ordering,
SRTP uses the sequence numbers within each entity
state stream |1|. But the main problem that SRTP
encounters is that it does not address the
synchronous collaboration because oI its NACK
based approach |9|.
TRANSPORT PROTOCOL
79

3.2. RMTP. Reliable Multicast Transport
Protocol
The main characteristic oI RMTP is its architecture.
In Iact, RMTP is based on a hierarchical structure
Iorming a multicast tree, with the sender as the root
node and the receivers as the leaI nodes |7|. In order
to have the tree, receivers are grouped into local
regions or domains based on their proximity in the
network.
In each domain there is a special receiver
(representative) called a Designated Receiver (DR)
who is responsible Ior |7|: Sending
acknowledgments periodically to the sender,
processing acknowledgements Irom receivers in its
domain and retransmitting lost packets to the
corresponding receivers. RMTP is composed oI three
components: The master that controls the sessions
and the communications, the DRs which can be the
senders and the receivers, and Iinally the receivers
that are only capable oI receiving the messages sent
by the DRs. The receivers choose their representative
DR: In Iact, each sender or DR sends a special
packet called the SENDACKTOME that contains
a value oI the Time to Live (TTL). The receiver will
then check the TTL oI each packet and choose the
one that has the largest value oI TTL. This chosen
node is going to be the DR oI that receiver.
The protocol works as Iollow |7|: The sender
sends the message to all the DRs (oI the highest
level) who will be responsible oI transmitting the
data to their local receivers. These receivers have to
send periodically their status to their DRs, in order to
enable them to check iI there is a lost packet. In this
case, DRs just perIorm and end-to end transmission
oI the right packet to the desired receivers and reduce
by that the ena-to-ena aelay signiIicantly. The DRs,
Irom their side, will send their own status to the
sender indicating which packets they have received
and which packets they didn`t receive. By using this
technique, there is only one ACK message sent to the
original sender per local region. This prevents the
problem oI ACK implosion. By reducing the
unnecessary retransmission that the original sender
has to send, in case oI a lost packet, this protocol
achieves high throughput and a low ena-to-ena aelay
|7|. In order to avoid the network congestion, the
source sends the data at a variable rate and this based
on the Ieedback Irom the group |11|. RMTP is
designed in a way to Iacilitate the scalability |7|, and
based on |14|, RMTP has been shown via an analysis
model to be the most scalable choice. RMTP is based
on the IP-Multicast technique. In Iact, the sender
does not have a track oI the receivers and this gives a
high aegree of scalability. Receivers can join and
leave the session when they want to without
inIorming the sender. Since RMTP allows users to
join the group at any time, it has two Ieatures that
allow the late users to catch up with the rest |7|. The
Iirst one is the immeaiate transmission request that
works as Iollows: when the user Iinds out that he
joined the group in the middle oI the transmission, he
requests Ior all the packets that he missed. These
packets will be sent using unicast. The second
Ieature is the aata cache in the senaer and the DRs.
In Iact, the DRs and the sender should have a buIIer
that contains the message sent. This Ieature allows
the receivers to request Ior a retransmission oI a lost
packet.
In order to provide a reliable delivery to all the
receivers and since the sender does not keep an
explicit list oI receivers, termination oI RMTP
session is timer based |7|. RMTP also supports
multi-level hierarchy oI local regions |7|. In that
case, the sender will receive only as many status
messages as there are DRs in the highest level oI the
multicast tree.
The main disadvantage oI this protocol is that it
does not guarantee the ordering oI the data sent to
the receivers. Another disadvantage discussed in |7|
is that the DRs are chosen by the receivers based on
the TTL oI the SENDACKTOME packet; and a
big number oI receivers can choose the same DR,
which result in an unbalanced tree.

3.3. SCTP. Synchronous Collaboration Transport
Protocol
SCTP is a host-to-host layer protocol especially used
to ensure the collaboration among users. It is scalable
and Iast due to the utilization oI IP multicast |8|.
SCTP is based on the notion oI an Interaction Stream
which means that a series oI update messages,
related to a sequence oI interactions oI a user with a
shared object, is grouped into one Stream |9|. This
stream is composed oI two types oI messages: key-
update messages and regular update messages. The
update messages represent the position or the motion
oI an object, and are sent through the best eIIort
transport. The key update message represents the last
update message sent and has to be delivered reliably.
From the packet's header, the receiver can identiIy
which shared object is being interacted with. The
packet also provides stream ID and sequence number
inIormation. streamID indicates the ID oI the current
interaction stream Ior this object, and the sequence
number indicates the position oI this speciIic update
message in the current stream |9|.
To ensure the reliability Ior the key update messages
|8,9|, SCTP uses an ACK-based architecture. This
means that the sender requests that these messages
have to be immediately acknowledged by the
receiver. In order to avoid the congestion oI the
protocol, the NACK based technique is used. In Iact,
80

when a packet is lost, the receiver sends a NACK |8|
to inIorm that he did not receive the packet and asks
then Ior a re-transmission. SCTP signiIicantly
improves the users` ability to collaborate on a
network where delay and packet loss is evident.
However, it was unable to solve the problem oI jitter
and cascade packet loss that it encountered.
One oI the signiIicant obstacles that SCTP
encountered is the ACK implosion problem. In Iact,
in order to realise reliability, SCTP uses only the
ACK-based approach and this leads most oI the time
to the main inconvenient ACK implosion problem.

3.4. SRM. Selective Reliable Multicast
SRM is a Iramework that has been designed in wb, a
distributed whiteboard application, which has been
used on a global scale with sessions having Iew
hundred participants |6|. This protocol is eIIicient
|14|, robust and scale well when it is used Ior large
networks and large sessions.
SRM is designed in a way to deliver all the data to
all the group members not including any particular
delivery order |10|. The transport method is the best
eIIort, but the reliability is built on an end-to-end
basis. For the delivery, SRM is based on the IP
multicast, but it added a special Ieature: in Iact, SRM
Iorces all the members that want to receive the data
sent to the group, to announce themselves by sending
a 'join message multicasting it to all the members
oI the group |10|.
When a member generates new data, it sends it to
the multicast group. In order to keep a track oI the
packets received, every member has to send
periodically a session message that contains the
highest sequence number received Irom each
member |10|. Each receiver is individually
responsible Ior detecting the lost packets and this by
Iinding a gap in the sequence space |10|. In that case,
it just requests Ior a re-transmission oI the lost
packet. It starts by sending a negative
acknowleagment (NACK) to all members. Everyone
can then participate and send the repair. This is
important because the original sender does not have
to make the repair process especially iI the distance
1

between him and the NACK sender is large |10|.
With the involvement oI every member, SRM makes
the repair process Iaster |6,10|. The members that
participate in the repair process use the slotting-
damping technique. In Iact, when a member requests
Ior a re-transmission, it sends it to the multicast
group. The closest member (the one who has the
right packet) times out Iirst and multicast the repair

1
The aistance is calculatea using the session messages ana the
rouna-trip-time it takes for a packet to travel between two
members
packet. The other members that were supposed to
send a request, and hear the request already sent,
suppress their own request and wait Ior the repair.
Similarly, the members that heard the request, that
have the right packet and scheduled the answer,
suppress their repair packet Irom their buIIer when
they hear the answer oI the Iirst member.
The main concern oI SRM is the congestion control.
In order to avoid it, SRM uses the exponential back
off beIore the NACKS and repairs. But the main
issue that SRM encountered is the important delay
during the transmission oI the message.

4. THE PROPOSED MULTICAST TRANSPORT
As presented above, several protocols were designed
in order to Iind an eIIicient one that can satisIy all
Collaborative Virtual Environment CVE
requirements. But no one was able to meet all these
requirements, such as bandwidth Ior SCTP and
SRM, or ordering in RMTP or even synchronization
in SRTP. As the applications that use the CVE are
growing, the design oI an eIIicient protocol became a
necessity. In order to reach this goal, a hybrid
solution is chosen. In this section, we shall present
our new hybrid protocol, which is a combination oI
the Iour protocols presented above: SRM, SCTP,
RMTP and SRTP. Our scheme takes advantage oI
the best characteristics oI each oI the Iour protocols.

4.1 Architecture of our proposea hybria protocol
The architecture chosen Ior this protocol is the
RMTP`s architecture: the virtual environment is
going to be represented by a multicast tree. Users
that belong to the same region are grouped together,
and one receiver is designed to as DR, the
Designated Receiver. DRs are basically chosen by
applying the same technique as RMTP, i.e, a DR is
designed iI it has the largest value oI the Time to
Live (TTL) when sending the SENDACKTOME
packet. The receivers can be grouped into local
regions based on their proximity, or their
geographical positions.
The proposed protocol supports a multi-level
hierarchy oI local regions |7|. In this case, the sender
receives ACK only Irom the DRs oI the highest
level. The DRs oI a low level will be the receivers
Irom DRs oI high level and senders Ior the receivers
oI their own local region. This architecture was
chosen to minimize the number oI messages sent and
to avoid the problem oI the ACK implosion that the
other protocols, such as SCTP, encountered. It is also
used as a congestion control plan.
As previously mentioned, RMTP does not have to
know how many members a DR has in his local
region. This means that there is a good probability
that the inIormation would be missed by some
PROTOCOL
81

receivers: they are either going to miss all the
packets, or to miss some oI them and to ask then Ior
a re-transmission. In order to avoid this problem and
to avoid the unnecessary re-transmissions, we are
going to add this Ieature: Users can join a local
group but they have to inIorm the DR or the sender
beIore by sending an adhesion message. This
approach is used by SRM. In this case, we can
ensure that the DR has a speciIic list oI all the
receivers and that it is going to send the message to
all the members in the local region. New users can
request Ior all the packets that they missed. In that
case DR sends the packets by applying the
immediate transmission request approach described
beIore in the Section 3.2.
In what Iollows, we will present the Message`s
Iormat oI the proposed protocol that is used in the
Iorm oI an Interaction Stream, i.e., a sequence oI
update messages related to a sequence oI interactions
oI user with a shared object is grouped into one
Stream |9|. This approach is described above Ior
SCTP. The interaction stream is composed oI two
kinds oI messages: key-update messages and update
messages. The update messages represent the
position or the motion oI an object. The key update
message represents the last update message sent, a
Iinal state oI an object, or an update message that has
to be delivered reliably.
The packet`s header carries inIormation that allows
knowing iI the packet is a key-update message or
not.. The packet also allows identiIying which shared
object is being interacted with, the current interaction
stream Ior this object, and the position oI the speciIic
update message in the current stream. The notion oI
Stream Interaction is really important in the CVE. It
allows the users to know which object is shared at
that moment and to have a stream oI all the
interactions done on that object.
In our work, the messages are going to be sent
dependently oI their type. This technique is used in
SRTP. Our protocol will use one oI the above 3
modes, oI transport deIined by SRTP. The message
sent is going to be either an 'Update message or a
'Key-update message. Update messages are the
data that change Irequently (e.g., as position). They
do not need to be transIerred reliably and are going
then to be always transIerred using the mode 0. For
the key update message, they need to be transIerred
reliably. For these messages, we are going to use
either the mode 1 or the mode 2. In Iact, iI the key-
update message has to be sent reliably to a group oI
members, mode 1 is used. II the key-update message
has to be delivered to only one member, in the case
oI a retransmission oI a lost packet, then mode 2 is
used.
For mode 0, data that change Irequently, best-
eIIort service is required. This kind oI data can
tolerate errors: in Iact, even iI a data is missed, the
one that is delivered aIter is going to replace the
missed one. This does not aIIect the perIormance oI
the protocol; In mode 1, Ior data that must be
received reliably by all members who are in the same
multicast group, IP multicasting is used to ensure the
reliability; while in mode 2, a transaction with a
single, determined receiver in the multicast group,
reliable and timely transport is required and this by
applying TCP.
In the case oI the motion oI an object, we are going
to add the timer Ieature. In Iact, as the update
messages represent the data oI an object which is
constantly moving, we assume that these messages
are sent periodically every a certain period oI time.
Then iI a receiver did not get an update message
within that period, it sends a NACK message
requesting Ior the lost packet. OI course, iI the object
does not move anymore, than a key-update message
should have been sent, and the receiver will not wait
Ior another message and will keep its timer to 0. In
order to ensure the collaboration, the synchronization
and the minimum delay, an end-to-end delay is no
more than 100 msec Ior update messages. This limit
was proposed in |8, 9|, and is going to be used Ior
the proposed protocol.

4.2. Reliability, Detection ana Retransmission of a
lost packets.
DIS, CVE and C-HAVE applications require a
reliable transport Ior some packets in certain cases. A
reliable protocol is then obligatory Ior these
applications. The reliability oI our proposed protocol
is applied by the NACK messages. This approach is
used by SRM. The detection oI a lost packet is
assured by a timer: in Iact, the members that are
waiting Ior a message and that do not receive it
within the speciIied period oI time, send a NACK
message, to their DR, that contains the sequence
number oI the last packet received. Moreover, iI the
receiver gets an unexpected packet, he puts the
packet received in its buIIer and sends a NACK
message. The use oI the NACK-based approach was
chosen in order to avoid the ACK implosion
problem.
The re-transmission oI the lost packet is the task oI
the Designated Receiver in the multicast tree. When
a receiver Iinds out that he did not receive a packet,
he sends a NACK to his DR to inIorm him about the
lost packet. The DR receives the NACK message
containing the sequence number oI the missed
packet, and he sends (unicast) the lost packet to the
right receiver; iI there is more than one receiver, than
the DR has to multicast the lost packet to the
82

receivers. Since lost packets are recovered by local
retransmissions as opposed to retransmissions Irom
the original sender, end-to-end latency is
signiIicantly reduced, and the overall throughput is
improved as well.

4.3. Oraering ana Scalability
Although some oI the protocols described above,
such as SRM, do not satisIy the ordering, the
proposed protocol maintains the ordering by the use
oI the sequence numbers. In Iact, every packet
delivered contains a sequence number that helps the
receiver to order the packet received and to detect a
lost packet iI there is a gap in the sequence number.
Our work is the combination oI Iour protocols that
ensure scalability to all oI them. The proposed
protocol is designed then to be scalable and Iast.
Every time a receiver wants to join the multicast
group, he has to inIorm all the members by sending
an adhesion message. When the members receive
this message, they update their inIormation and they
send the message SENDACKTOME, so the new
member can elect his Designated Receiver.

5. CONCLUSION AND FUTURE WORK
Collaborative Virtual Environment (CVE) and
Collaborative Haptic, Audio and Visual Environment
(C-HAVE) are used in many scenarios. While many
techniques were discussed in the literature on how to
satisIy the Iollowing CVE requirements: scalability,
reliability, synchronization and minimum delay.
However, these protocols have Iailed to reach this
goal. In this paper, we have presented a hybrid
solution protocol combining SRTP, SRM, RMTP
and SCTP protocols and the advantages oI their
characteristics. Our proposed protocol has a
multicast tree architecture that allows it to avoid the
congestion and the end-to-end delay problems. It
uses also the transport modes described by SRTP in
order to ensure the reliability. As Ior the
synchronization, our hybrid solution uses the
Interaction Stream described in SCTP. Further
research is required to test our proposed protocol in
diIIerent CVE and C-HAVE applications in order to
improve its perIormance.

REFERENCES
|1| J. M. Pullen ana J. P. Laviano 'Adding Congestion Control
to the Selectively Reliable Transmission Protocol Ior Large-Scale
Distributed Simulation Fall 1997 Simulation Interoperability
Workshop paper 97F-SIW-018, September 1997
|2| J. M. Pullen ana N. Kakarlamuai 'PerIormance Issues Ior the
Light-Weight RTI IEEE Simulation Interoperability Workshop,
Orlanao, FL, September 1998
|3| J. M. Pullen ana J. P. Laviano 'A Selectively Reliable
Transport Protocol Ior Distributed interactive Simulation` Proc.
of the 13th Workshop on Stanaaras for the Interoperability of
Distributea Simulations, 1995
|4| D. M. Moen ana J. M. Pullen 'A PerIormance Measurement
Approach Ior the Selectively Reliable Multicast Protocol Ior
Distributed Simulation Proc. of the IEEE Distributea Simulation
ana Real Time Applications Workshop, Cincinnati, OH, August
2001
|5| J. M. Pullen 'Reliable Multicast Network Transport Ior
Distributed Virtual Simulation Proc. IEEE Workshop on
Distributea Interactive Simulations ana Real-Time pplications,
1999 (DISRT 99), pp. 59-66
|6| A. Siafa 'Protocol Multipoint Fiable et ordonn pour
applications coopratives assynchrones` Univ. De Savoie 1998
|7| S. Paul, K. K. Sabnani, J. C. Lin ana S. Bhattacharyya
'Reliable Multicast Transport Protocol IEEE Journal on Selectea
Areas in Communications, April 1997
|8| S. Shirmohammaai ana N. D. Georganas 'An End-to-End
Communication Architecture Ior Collaborative Virtual
Environments` Computer Networks Journal, Jol. 35, No. 2, pp.
351-367, February 2001
|9| S. Shirmohammaai ana N. D. Georganas 'Collaborating in 3D
Virtual Environments: A Synchronous Architecture Proc. IEEE
International Workshop on Enabling Technologies.
Infrastructure for Collaborative Enterprises, Knowleage Meaia
Networking Workshop, National Institute of Stanaaras ana
Technology (NIST), U.S.A., June 2000, pp. 35-42.
|10| S. Floya, J. Jacobson, C. G. Liu, S. McCanne, ana Lixia
Zhang 'A Reliable Multicast Framework Ior Light-weight
Sessions and Application Level Framing IEEE/ACM
Transactions on Networking, November 1996
|11| D. DeLucia ana K. Obrac:ka 'A Multicast Congestion
Control Mechanism Ior Reliable Multicast 3ra IEEE Symposium
on Computers & Communications, Athens, Greece, 1998
|12| S. K. Kasera, J. Kurose ana D. Towsle 'Scalable Reliable
Multicast Using Multiple Multicast Groups In IEEE/ACM
Transactions on Networking, June 2000
|13| B. N. Levine, S. Paul ana J.J. Garcia-Luna-Aceves
'Organizing Multicast Receivers Deterministically by Packet-Loss
CorrelationMultimeaia Systems Journal, 2002.
|14| P. Parnes 'The mStar Environment Scalable Distributed
Teamwork using IP Multicast.` Master Thesis, September 1997
|15| J. M. Pullen 'Limitation oI Internet Protocol Suite Ior
Distributed Simulation in the Large Multicast Environment ", RFC
2502, February 1999.
|16| J. K. Shapiro, D. Towsley ana Jim Kurose 'Optimization
based-Congestion Control Ior Multicast Communication Proc. of
Networking 2002
|17| A. Boukerche, S. Shirmohammaai, A. Hossain 'Prediction
Based Decorators Ior Distributed Collaborative Haptic Virtual
Environments J. Computer Applications in Technology, Special
Issue in Collaborative Multimeaia Applications in Technology
2006
|18| A. Hossain 'Virtual Reality Simulation Modeling Ior Tele-
Surgery and Tele-Haptic Class oI Applications, Master Thesis,
Univ. oI Ottawa 2005
|19| S. Shirmohammaai ana N. H. Woo 'Shared Object
Manipulation with Decorators in Virtual Environments Proc. of
the 8
th
IEEE International Symposium on Distributea Simulation
ana Real-Time Applications (DS-RT04)
|20| Xiaofun Shen, Jilin Zhou, Abaulmotaleb El Saaaik, ana
Nicolas D. Georganas 'Architecture and Evaluation oI Tele-
Haptic Environments Proc. of the Eighth IEEE International
Symposium on Distributea Simulation ana Real-Time Applications
(DS-RT04)

83