[attachment=1059]
ABSTRACT
Managing packets in distributed multimedia environment involves coordinating and synchronizing multiple datastreams. The Ensembles Coordination Program provides the required coordination, reduces delay using path selection and message rebroadcasting, and allows the end application to manage the synchronization within the streams.
One immediate advantage of this mechanism (ECP) is the reduction of data rebroadcasts, because nodes with more than one adjacent nodes must send the data and only to those adjacent nodes.

Introduction
Distributed multimedia conferencing systems break the information to be transmitted (voice, video, data) into packets which they transmit in a packet stream. The system must maintain packet order and stream interrelationships from origin to destination. Managing packet delivery among multiple users is particularly difficult in conferencing systems, which typically involve many source and destination nodes. For example ,this system often require extended routing time and additional buffer space for merging data from multiple sources, which delay packet delivery.
Most work to date on packet management in distributed multimedia environments such as team workstation and Etherphone focuses on guaranteeing isochronous presentation rates over a network where thereâ„¢s single source and destination. To support distributed multimedia conferencing systems we need a system that can coordinate delivery of multiple packet streams from multiple sources with minimal delay, allowing destination applications to manage synchronization within the streams.
This report discusses the coordination and synchronization of multiple data streams in a distributed interactive digital multimedia (DIDM) group with multiple senders and receivers. The Ensembles Coordination Program (ECP) performs the required coordination and synchronization using path selection and rebroadcasting to reduce delays. ECPâ„¢s routing mechanism differs from multicasting because while it provides data segment routing by duplicating messages, it also coordinates multiple interdependent data streams.

Coordinating Distributed Multimedia Data
This coordination methodology is independent of the network delays caused by the underlying network protocols. Delays caused by the network could however cause jitter. Jitter occurs when, for instance a word or image is played back with a stutter. In a conference, if two people speak at the same time, each personâ„¢s voice must coincide with the formation of the words in that personâ„¢s video image.
In ECP , an ensemble is a collection elements A from a stream to be presented to an application with the collection of elements B of another stream, for n streams .Ensemble coordination is the presentation of all A and B elements in their required synchronization order to an application .E-systems are nodes in the infrastructure.
We can coordinate the elements of multiple data streams at three points: a common source or distribution center, the destination or intermediate points along the path. This report concentrates on problems that occur along the source-destination path. Key issues are minimizing the processing the to determine the routing of stream elements , establishing adequate buffering at all nodes in the network, and ensuring that the proper data segments are available for synchronous presentation.
The related problems such as graph or network partitioning, fault tolerance, dynamic group membership, transmission control protocol/internet protocol versus asynchronous transfer mode and other network protocols. The design of this procedure doesnâ„¢t preclude inclusion of this items in the future.
Processing at en E-system occurs at two stages. Stage one reads all ensembles content definition and their sources and their targets. It also reads definition of the network graphs, nodes and edges. With this information, stage1 creates the data structures required to perform synchronization. Stage2 transmits and receives the multimedia data objects and presents them, in proper synchronization, to the output processes. TCP/IP guarantees single source ordering.
The object model represents the multimedia data streams and their operations. A multimedia stream corresponds to the data-specific for one or more media. For example an object can contain a video data stream and an audio data stream with a time dependency between them. An Ensemble differs from a stream or object in that streams donâ„¢t contain specifications for related data, and an object canâ„¢t co-ordinate disjoint streams. Streams or objects might require data to be presented together in real time synchronization, thus imposing a dependency on the availability that all portions of a presentation moment be available within some time span. In a multimedia group application, where any group member can simultaneously be in multiple groups, Ensembles must observe all the three ordering properties.
The ordering properties are as explained below:
Single Source ordering: If messages M1 and M2 originate at the same site, all receivers within a specific multicast group will receive them in the same order.
Multiple source ordering: If different sources send messages M1 and M2 all recipients in the group will receive them in the same order.
Multiple Group ordering: If messages M1 and M2 are delivered to two processes, they are delivered in the same order to both processes, even if they originated at different sources.
Note that there is a clear distinction between doing and seeing in multimedia conferencing. When a conference participant does something feedback might not be instantaneous. All participants, including the participant performing the action will see the reaction of the moment taken in the same way, ordered with respect to the other data streams by the three properties mentioned previously. Note that no common global time exists. All participants see all events in the same order but not necessarily at the same real time.
This report makes no pre-judgments about implications. On a fast LAN feedback will be nearly instantaneous. With other network functions, there might be a noticeable delay with doing and seeing. For some types of conferences or data streams, some delay might be acceptable; for others, the same amount might tax participants adaptability or disorient them. For example if a video is sporadically interrupted, viewers can continue to mentally process the information while the voice continues, but when an audio information is sporadically interrupted, the human listener experiences severe disorientation.
Synchronization types
Intra object synchronization: It is the time relation between the units of a single time dependent media object.
Inter object synchronization: It is the time relation between the multiple media objects at a single range.
Some application requires provisions where the processing program must digitize and normalize some signals, then add to them some other signals. On playback the program at the origin must subtract its own signal from the summation. ECP handles these problems using a third type of synchronization called Site synchronization.
Site synchronization: In this type of synchronization ECP provides the required data segment to the multimedia applications, which then synchronizes the inter object presentation. ECP delivers the data at different nodes in the conference, such that all the same nodes display the same object identical synchronization and delay within and between the objects.
Global synchronization: In this type of synchronization all sites provides all three types of synchronization in a near universal time presentation of object sequences, as in a live television broadcast received at multiple locations.

Ensembles coordination ensures that the transmission of element of a multimedia conference honors the distributed system properties with minimal buffering requirements and meet the requirements of all three synchronization types. ECP differs from mixing or multiplexing. In Ensembles the individual data streams arenâ„¢t physically merged. Rather than ECP transmits them as separate TCP/IP messages and Ensemble coordination ensures that the related segments of each streams are transmitted before the next set of segments.

Architecture and Implementation
ECP manages multiple segments of multiple data streams as they traverse a network of distributed instances of a multimedia application. ECP is logically positioned between the network interface and the multimedia application.
Structure
To simplify development and testing, the current implementation is a single stand alone program that opens multiple data files, provides inter stream coordination, and displays data. However the program structure is such that it could be truncated to coordinate data only, allowing a real multimedia application to provide and display the data segment.
In the truncated version, a multimedia application developer could test an application with a copy of ECP running at many nodes without modifying, recompiling, or changing the parameters. In this case all nodes running the ECP is called an E-system.
Each E-system has two control files
1. NE.dat: This contains the virtual names assigned to all nodes along with their network names, a list of all nodes and edges in the conference graph, and a list of Ensembles names with their corresponding stream names.
2. ERULES.dat: It contains the list of rules expressing the relationship between the streams and ensembles.
To initiate a conference, the conference operator starts all E-systems. When the conference operator determines that the E-system have initialized, he/she initiates the conference start via the command interface. At the initialization, each E system communicate with each other. The current initiation Simplifies the overall program structure, letting ECP concentrate on data routing and coordination.
System Development
A sequential dependency exists within a single stream in multimedia presentation. For example, a multimedia program must reproduce speech sounds as spoken i.e in the same order or the meaning is lost. A sequential dependency also exists across streams. For example, in Ensemble E1 in figure given below, if stream s1 is voice and stream s2 is speaker's image, the voice must match the movement of persons lips in the video stream. Thus at any instant the elements of one stream must be synchronized with the elements of all the other streams related to that presentation instant. In a movie, this relationship is called a frame and the synchronization colloquially called a lip synchronization. In ECP, it is an Ensemble.

Representing Conferences
Let Sn represent the nth stream in Ensemble Ee. Data stream coordination requires that the ith element of stream S1 is presented simultaneously with the jth element. A ratio of the stream elements prevents the streams S1 and S2 from being transmitted
At a rate where i matches j, rather a relationship exists between the values of i and j. We thus have an expression , Ee ($,&,¦) relating the presentation requirements of the frames of streams S1, S2, ¦ within Ee, where $ and & represent the relation i and j to the whole Ensemble. The entire conference, C, as shown in the figure can be represented by

Where E is an Ensemble, e is the Ensemble number, m is the maximum Ensemble number determined for the conference from the NE.dat(file) and $ is the number assigned during the conference graph construction and
E=[Sm,Qn]
Where S represents a stream, Q is the quantity of data segments in the stream, and n is the stream number (thus, Qn is the quantity of data segments in stream n). ECP receives these rules from the conference file ERULES.dat . The program determines the contents of an Ensemble by the set of its ordered pairs of stream S and the quantity Q of segments per stream.
Minimizing Delay

As previously noted, a movie with both a audio and an audio portion contains multiple elements of video data for one element of audio information ( video data consists of 30 frames per second ). A segment of this Ensemble would thus be 30 video elements and one audio element. This would be now reflected in the ERULES.dat file with the record E1 (S1,30) (S2,1).
Given the synchronization requirements and the desire to reduce buffering, an Ensemble node requires a routing mechanism that will ECP transmit the ith portion of S1 with the ith portion of j and so on, as a relative cohesive unit. By relatively cohesive, I mean that users should receive the segments within a short enough time span so that they wonâ„¢t preceive a program related delay between Ensembles i.e. ECP doesnâ„¢t physically merge ( or mix or multiplex) the individual stream segments that form an Ensemble into a single message, but still presents them as a single synchronized unit. Other researchers have addressed the ability to handle other sources of delay; this research should be incorporated in a more universal solution.
We can extend interobject synchronization to more than two streams, as when the signals from the simulator are separately recorded and then all recordings are played together. Because multimedia conferencing is human communication every node, $, in a conference of C nodes should display the same Ensembles such that all human conference participants preceives the Ensemble with some predefined offset # from each instant in time as measured at the ensembleâ„¢s originating site. ECP isnâ„¢t concerned with the value of this offset other than to attempt to quantify itâ„¢s effects on data presentation at the destination. Much research on quality of service has focused on the value of #.
This report concentrate on the problems involved with multisource, multidestination synchronization of interdependent data streams. In a multimedia environment, where multimedia programs requires large quantities of data and many streams, buffering alone might provide neither the necessary synchronization nor the dataâ„¢s close to real time requirements. Current streaming techniques donot address the merging separate source stream requirements.
Merging and routing Streams
The figure drawn previously shows three data streams S1, S2, S3 originating at separate locations SO1, S02 andSO3. ECP must offer these streams which constitute Ensemble E1, all three synchronization types at each of the final destinations D1, D2 and D3. Streams S4 and S5 compose Ensemble E2. A time dependency exists between streams E1(1,2,3)(#,$,..), where #, $ etc represents the relationship of the number of data packets in each stream that must be transmitted with elements of the other stream to form the Ensemble. Depending on the type of conference we might or might not want to make the presentation at destination D1 simultaneous with the presentation at destination D3( delayed presentation must be desirable in replay systems. The same dependencies exist for E1.
E-system run a DIDM application using TCP/IP and donâ„¢t modify the underlying operating system or network processing facilities. E-system which are neither stream sources nor final destinations, are intermediate synchronization stations. Their purpose is to merge streams from multiple sources before the Ensemble move to the next graph node.

For Example in the figure drawn previously we must forward stream S3 from SO3 to D1 with S1 and S2(from ISS4) but independently of D3, so the multimedia application can process it there with the re with the proper elements of itâ„¢s Ensemble from S1 and S2.Note that this Ensembleâ„¢s methodology doesnâ„¢t directly address dynamic reconfiguration of the network graph, although the implementation allows for it. Virtual nodes are mapped to IP addresses, which could be dynamic.
Flits
Flits are flow control units the header of which deterministically controls the flow of all succeeding datagrams parts. Flits strongly influenced the development of the ECP routing scheme. Instead of flits, however the ECP uses a path node vector(PV) and a distribution vector (DV) both computed at program initialization. Tha PV determines all destination for each data streams. The DV determines, for each node, all sites that are one graph distant , and which must receive the the current data stream segment(or data element). To the best of my knowledge , the flit and DV have so far implemented in hardware used to interconnect large scale mesh or cube connected multicomputers.
Managing Stream Segments
Normally three arrays to manage the selection of segments for display or transmission. They are Required, Avail, and Avail_S. Required specifies the number of segments per Ensemble and stream at the current node. Avail and Avail_S specifies the number of segmrnts currently in the buffer , either awaiting retransmission or display(Avail) or original transmission(Avail_S).ECP assigns number to all streams and Ensembles, and then indexes the three arrays by Ensemble and stream number. The ERULES.dat file directly determines the values in Required. It determines the values in other two arrays at run time as segments arrive(either from other node or from a file reading thread).
To control the use and removal of the Ensemble and stream segments , each stream is a C++ object. Each object contains a list of available segments in the stream and arrays with the starting and ending list indexes of the segments in the current Ensemble. During program execution, the number of segments available for Ensemble transmission can exceed the number of segments required for the current Ensemble. This occurs because the various segments come from different nodes. These index arrays together with Required, Avail, Avail_S provide the information needed to ensure transmission a complete Ensemble. In addition because , multimedia buffers can use any stream, ECP canâ„¢t purge the buffer segments until the application program no longer needs the segments.
The Ensemble Algorithm
The Ensemble coordination must perform several initializations before it can begin processing conference data. Once the system is initialized , ECP moves into itâ„¢s operational stage, during which it accepts data for transmission and receives incoming data for display. The Ensemble algorithm describes these operations.
Initialization
First create the graph, G, and a LEDA( Library of efficient Data Structures and Algorithms) graph array, G, representing all nodes in the graph. List source nodes first, destination nodes second, and intermediate nodes last.
Next compute the adjacency vector (AV) for the current node. This is directly available using the LEDA function, G.adj_nodes.
For receiver nodes , use the LEDA Graphwin function to create a window for each Ensemble to be played at this node. Graphwin is a platform independent mechanism that lets users draw windows and insert graphics and text. Next for each Ensemble originating at this node store the information computed in 1, 2, 3(below) in the stream object for each node in the stream.
1. Given the streams starting and ending locations determine the path to all the stream destinations.
2. Create the path node vector, the path node vector is a string of bits, one bit per graph node. A bit set to 1 if the node is supposed to process (display or transmit) this stream, otherwise itâ„¢s 0.
3. Compute the DV for each stream, the DV is a string of bits, one per graph node, where a 1 represents a node in the path of the stream from the current node to the next destination.
Operation
For each stream of this Ensemble:
1. Obtain a stream element.
2. Attach itâ„¢s Position Vector.
3. Send the elements of this data stream to nodes represented by 1â„¢s in the DV.
Then for each Ensemble passing through or originating at this node, if all required Ensembles elements are available (either from the network or from the multimedia application).Next use the Ensembleâ„¢s stream coordination rules to create a list of elements to be forwarded. Extract the PV from the stream element. Compute the Distribution Vector doing the logical AND of the bits of Position Vector with the bits in Adjacency Vector for the current node. Then,
1. Send the elements of this data stream to the nodes represented by 1â„¢s in the DV, and
2. Update the control arrays to indicate this ensemble has been processed.
Building a Distribution Vector
Given the directed graph G of the nodes in the figure drawn previously compute the adjacency matrix for each node at initialization. A modified Dijkstra subroutine to the graph to determine the routing for every stream and to build the Distribution Vector to control the routing through the network. Thus, the path for stream S3 are
SO3, ISS3, D1
SO3, ISS3, D3
Once this paths are found, it is merged to single path list with no duplicate entries(SO3, D1, D3, ISS3),using the same ordering of nodes the Adjacency vector is computed which is as written below

where the overbar indicates that the node isnâ„¢t in the path for this stream in the path for this stream in the Ensemble and 001001010010 is the Position vector for the stream SO3.
To determine the routing from the current node , SO3, I perform a bitwise AND of the Position vector for S3(001001010010) with the Adjacency vector for SO3 (000000000010), giving the Distribution vector and (000000000010) representing ISS3 as this elements next destinations.
At ISS3, (000001110000) is the Adjacency vector , perform an AND operation on this result with the position vector sent with the stream (001001010010) to get the Distribution vector (000001010000), which corresponds to nodes D1 and D3. Thus, these are this elementâ„¢s next destinations.
At D1 and D3, the program recognizes that the current node is the target ( the resulting AND operation will be all zeros).The window created for Ensemble E1 will display the element the element in the corresponding elements from the SO1 and SO2 when they arrive.

Transmission of Data and Protocol Used
ECP creates an object class, Gnodedata, that maintains all the information about a node and includes multiple occurances of the class Ensemble “ one for each group of data streams the node will process. ECP accesses a Gnodedata object from the parametric data at a node n of the graph G. When the algorithm determines that a stream is to be processed , the ECP at the node accesses all the data pertaining to that stream from within Ensemble E. The Gnodedata maintains such relevant data such as mapping from the virtual to real nodes and mapping streams identifiers to and from Ensembles and Adjacency vector. Ensemble E stores identifiers for it™s streams , Position vectors for each streams and rules for merging streams, such as those used for synchronizing Ensemble streams in the Algorithm.
When an E system transmits a stream element, ECP concatenates the stream with identifying data, such as a stream ID and PV. Using the stream ID, we can get directly to to the Ensemble data in the Gnodedata object, then determine which other streams will be available and whether or not they are. Each receiving location can use this data to quickly determine where to forward the element when all Ensemble content is available. This organization let us rapidly map from stream to ensemble and viceversa and from virtual node to IP address. It also provides the underlying structure for graph traversals.
One immediate advantage of this mechanism is the reduction of data rebroadcasts, because only nodes with more than one adjacent node must send the data only to those adjacent node. Additionally, in the absence of graph reconfiguration, the ECP at the nodes doesnâ„¢t have to recomputed complex multicast routing at each rebroadcaster. In the event of reconfiguration, the routing.
Computation is still a simple AND operation, although all vectors would have to be modified. The underlying TCP/IP manages the actual routing to the specified graph node. ECP also lets any node provide update information to other nodes with respect to Ensembles and streams for existing Ensembles. The basic program structure, however, doesnâ„¢t preclude dynamic changes to the graph.
RTP
RTP is designed as an end-to-end transport protocol that is suitable for unicast or multicast transmission of real-time data, such as interactive audio or video. RTP follows the two principles:
Application Level Framing: The key architectural principle is Application Level Framing. The idea is that the application should break down the data into aggregates, which are meaningful to the application, and which do not dependent on a specific network technology. These data aggregates are called Application Data Units (ADUs). The frame boundaries of ADUs should be preserved by lower levels, that is, by the networksystem.
The rule, by which the size of an ADU is chosen, states that an application must be able to process each ADU separately and potentially out of order with respect to other ADUs. So, the loss of some ADUs, even if a retransmission is triggered, does not stop the receiving application from processing other ADUs. Therefore and to express data loss in terms meaningful to the application, each ADU must contain a name that allows the receiver to understand the place of an ADU in the sequence of ADUs produced by the sender. Hence, RTP data units carry sequence numbers and timestamps, so that a receiver can determine the time and sequence relation between ADUs. The ADU is also the main unit of error recovery. Because each ADU is a meaningful data entity to the receiving application, the application itself can decide about how to cope with a lost data unit: real-time applications, such as digital video broadcasting, might prefer to simply ignore a few lost frames instead of delaying the presentation until the lost frames are retransmitted, whereas file transfer applications cannot accept the loss of a single data unit. In addition, if the application has the choice of how to deal with a lost unit, the sender can decide whether to buffer the data units for potential retransmission, to recompute the lost units if requested again, or to send new data that which diminishes the harm done by the loss of the original ADU.
Integrated Layer Processing : Because application level framing breaks down the data in pieces that an application can handle separately from other data units, all processing of a single, complete ADU can be done in one integrated processing step for reasons of efficiency. This engineering principle is called Integrated Layer Processing. Layered isolation, as employed in conventional protocol stacks, is suitable for the network layer and below, they argue that many of the functions of the transport and above layers could be structured in a way that would permit the use of the more efficient IntegratedLayerProcessing. Especially for RISC systems, whose performance is substantially limited by the costs of memory cycles, an integrated processing loop is more efficient than several, isolated steps that each read the data from memory, possibly process it in someway, and write it back to memory.
RTP is used in combination with other network or transport protocols---typically on top of UDP---as visualised in Figure.

The RTP specification recommends the use of two different generalised destination ports within one RTP session, one port for the reception of RTP payload packets and one for RTCP control packets. If RTP is used in conjunction with RSVP, one RTP session corresponds to two RSVP sessions, which are identified by the addresses of the RTP data and control destination ports, respectively. RTP supplements the data delivery functions of the underlying protocols with the following services:
Payload type identification.
Sequence numbering.
Timestamping.
It should be noted that RTP itself does not make any QoS commitments, does not guarantee reliable, timely, or in-order delivery, and does not enforce any error treatment measures. However, extensions, add reliability to RTP for applications that cannot tolerate packet loss, for instance white-board applications. The accompanying RTP Control Protocol (RTCP) facilitates monitoring of the delivery QoS, and conveys rudimentary information about the participants of an RTP session.
RTP and RTCPâ„¢s specification serves only as a protocol framework; RTP is intended to be tailored to the needs of particular applications by additional specifications:
Payload format specification documents, which define how a particular payload is to be carried in RTP. Currently, payload format specification RFCs exists for H.261 video streams, for CellB video encoding], for JPEG-compressed video, and for MPEG video.
A profile specification document, which defines a set of payload type codes and their mapping to payload formats, as well as any extension or modification of the RTP message headers that are necessary for a specific class of applications.
RTP Payload Transmission
RFC 1889 introduces the term of an RTP session to describe a set of participants that communicate via a particular pair of destination transport address, for example a multicast IP address together with two UDP ports for control and payload data. Within one session, only a single payload type and the associated control information are transmitted; this rule has several consequences:
Multiple RTP sessions must be used for multimedia applications.
Demultiplexing of the received data streams by the payload type is avoided, following the principle of integrated layer processing.
Different QoS reservations can be established for each session in accordance with the different needs of each medium and each receiver's possibilities.
An RTP packet consists of a fixed header, a variable-length list of sources that contributed to the payload in the packet, a potential header extension as defined in a profile specification, and the actual payload, which is encoded according to a payload format specification.
The fields of highest importance in the RTP packet header are:

Synchronisation source (SSRC) identifier. A receiver uses the synchronisation source identifier to demultiplex the packets received via one destination port. Therefore, each SSRC identifier must be unique within one RTP session. All packets from one synchronisation source fit into the same timing and sequence numbering space.
Sequence number. The synchronisation source increments by one the sequence number of each RTP data packet sent in one session. This number can be used by a receiver to restore the sequence of packets disordered during the transmission, to detect packet loss, and to compute the number of expected and lost packets.
Timestamp. The timestamp describes the sampling time of the first octet of the payload data carried by the packet. The sampling instant must be measured by means of a clock, which produces timestamps increase monotonically and linearly in time. The clock frequency that is used for the mapping of timestamps to wall clock time should be layed down in a protocol or payload specification, or could be recomputed with the help of NTP timestamps sent within RTCP packets. A receiver can use the timestamps for intra- and inter-stream playout synchronisation as well as for inter-arrival jitter estimation.

An RTP data packet does not contain any length indication; an application must either rely on the protocol used beneath RTP to provide framing mechanisms, or, in case the underlying protocol provides a continuous octet stream abstraction, define a method of encapsulating RTP packets in the octet stream.
Control and Feedback Information
RTCP control packets are sent periodically (with small random time variations to avoid traffic bursts) to the same (multicast) host address as the RTP data packets. Their content facilitates:
QoS monitoring and congestion control. The primary function of RTCP messages is to provide feedback on the quality of the data distribution. The conveyed information can be used for flow and congestion control, to control adaptive encodings, and to detect network faults.
Applications that produce payload data generate RTCP sender reports. These reports contain counters of sent packets and octets that allow other session participants to estimate a sender's data rate.
Applications that have recently received packets issue RTCP receiver reports, which contain the highest sequence number received, loss estimations, jitter measures, and timing information needed to calculate the round-trip delay between the sender and the receiver.
Media synchronisation. Sender reports contain an NTP timestamp and an RTP timestamp. The RTP timestamp describes the same instant as the NTP timestamp but is measured in the same units as the timestamps issued in the data packets of the sender. These two timestamps allow to synchronise a receiver's playout clock rate with the sampling clock rate of the sender. In addition, a receiver can use this RTP/NTP timestamp correspondence information to synchronise the playout offset delay of related streams.
Member identification. RTP data packets and most RTCP packets carry only an SSRC identifier but convey no other context data about a session participant. Therefore, RTCP source description packets are sent by both data senders and receivers. They contain additional information about the session members, especially the obligatory canonical name (cname), which identifies a participant throughout all related sessions independently from the SSRC identifiers. The representation of the canonical name must be understandable by both humans as well as machines. Other conveyed information includes email addresses, telephone numbers, the application name as well as optional application-specific information. An application that decides to leave a session must transmit an RTCP bye packet to indicate that it will not participate in the session anymore.
Session size estimation and control traffic scaling. The total control traffic generated by all participants in a session should not exceed a small percentage of the data traffic, typically 5 percent. The control messages from other session members enable a participant to estimate the session size and to adapt its control packet rate, so as to remain within the limit of the control traffic share. So, RTP scales up to large numbers of participants.
Different schemes have been developed to exploit delivery feedback information in order to estimate the network congestion state and to adjust the application bandwidth accordingly. These schemes work for applications that can scale their media quality and their data rates to a given bandwidth value.
Busse, Deffner, and Schulzrinne propose a simple though interesting and workable mechanism. The fraction of lost packets, conveyed by normal RTCP receiver reports, is used as the primary indicator of the congestion state of the network: a data sender classifies the network path to each receiver as UNLOADED, LOADED, or CONGESTED. Depending either on the average classification of all paths or on the worst path, the sender makes an adjustment decision about its sending behavior it may increase, hold, or decrease its application bandwidth.
In a different approach instead of using the information from standard RTCP messages, a sender solicits congestion state information from a subset of the receivers, and then decides about appropriate bandwidth adjustments.

Current implementation
In February 2001, ECP began running on multiple systems. To reduce extraneous delay factors, the program uses textual data only. This should also simplify performance measurement. In May 2001, I had enough physical systems to fully implement the network graph in Figure 1. In August 2001, I began working with sufficiently large data streams (more than 200 records) to establish some statistically meaningful information. Raw measurements show that Ensemble segments arrive within 10 ms of each other from systems that are within one hop differential from their destination, even though delays between Ensembles can exceed this by a factor of 4. This work continues.
Configuration
The system is currently implemented on seven systems running SunOS 5.6 (UNIX), compiled with g++ and one MS Windows98 machine, and compiled with MS Visual C++ 5.0. The Windows machine controls the systems using Hummingbirdâ„¢s Exceed software, so all the UNIX systems appear on the Windows 98 screen. Graph manipulation functions come from the LEDA package which is also provides all the classes in the C++ Standard Template Library, as well as application independent, cross-platform windowing(X and MS).
Scalability
Because the program maintains the networkâ„¢s graph structure, growth of the current implementation design is restricted by the amount of virtual memory available. The time available to search the graph for all streamsâ„¢ routing at initialization limits the number of nodes in the network. A larger graph would slow program startup, but would only minimally affect the steady-state performance. The search for the data structure for a graph node is O(n). The number of streams is not a major performance bottleneck as the search for stream information is also O(n).

Conclusion
The Ensembles coordination program will be used in almost all the multimedia application since it reduces the buffer required and minimizes delay. The next step in this field is to transmit the effects of transmission delays on the coordination and presentation of data. Given that the graph is available at all nodes, ECP could easily allow dynamic reconfiguration as well as operations on the graph itself. A program segment can reduce the information to textual format for transmitting the new graph to all nodes. ECP could also extend graph to add new conference attendees, which would allow users to join and leave a continuing conference at will, and new conferences.

References
http://mpi-sb.mpg.de
http://computerpublications/dlib
csdl.computercomp/mags
starbaknews_events/


ACKNOWLEDGMENT

I express my sincere thanks to Prof. M.N Agnisarman Namboothiri (Head of the Department, Computer Science and Engineering, MESCE),
Mr. Sminesh (Staff incharge) for their kind co-operation for presenting the seminars.
I also extend my sincere thanks to all other members of the faculty of Computer Science and Engineering Department and my friends for their
co-operation and encouragement.
Ajan Daniel Kutty

CONTENTS
INTRODUCTION
COORDINATING DISTRIBUTED MULTIMEDIA DATA
o Synchronization types
ARCHITECTURE AND IMPLEMENTATION
o Structure
o System Development
REPRESENTING CONFERENCES
o Minimizing Delay
o Merging and routing Streams
o Flits
¢ MANAGING STREAM SEGMENTS
o The Ensemble Algorithm
TRANSMISSION OF DATA AND PROTOCOL USED
o RTP
o RTP Payload Transmission
o Control and Feedback Information
o Current implementation
o Configuration
o Scalability
CONCLUSION
REFERENCES