Real Time Protocols

Real Time Protocols

This section gives a brief overview or real time protocol and real time control protocol.

Data Transport

The real time protocol is a data transport protocol. Real time protocol is designed to support multicast communication in interactive multimedia applications, such as audio and video teleconferencing and distributed simulation. It deals with data delivery and uses services provided by lower layer protocols. RTP can run on the unreliable datagram protocol UDP. It uses UDP’s multiplexing and error control services and compensates UDP with its own sequencing function.

RTP is designed to be scalable from a few participants to thousands of participants in multicast communication and to be able to accommodate heterogeneity of sources, receivers and networks. RTP assumes that multicast group membership may change dynamically. RTP is often integrated with applications. According to RTP, the audio and video are transmitted separately. Each medium uses a separate multicast network address and a pair of UDP ports, one for data packets and one for control packets.

A data packet consisting of the fixed RTP header, a possibly empty list of contributing sources and the payload data is called a RTP packet. An encapsulation of the RTP packet to be deï¬Âned is required by some underlying protocols. Typically, one packet of the underlying protocol contains a single RTP packet, but several RTP packets may be contained if permitted by the encapsulation method.

RTCP control Protocol

The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs three major functions: (Schulzrine, 2003)

1. The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP’s role as a transport protocol and is related to the flow and congestion control functions of other transport protocols. Sending reception feedback reports to all participants allows one who is observing problems to evaluate whether those problems are local or global. This feedback function is performed by the RTCP sender and receiver reports.
2. RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. The CNAME is required by the receivers to keep track of each participant. The CNAME is also required to associate multiple data streams from a given participant in a set of related RTP sessions, for example, to synchronize audio and video.
3. The first two functions require that all participants send RTCP packets, and hence the rate must be controlled so that RTP can scale up to a large number of participants. Each participant can independently observe the number of participants by sending their control packets to all the others. This number is used to calculate the rate at which the packets are sent.

Communication in Multicomputer Systems

Like packet switched networks, multihop networks used to interconnect processors I massively parallel machines also consist of crossbar switches connected by full duplex links. Unlike packet switched networks, these networks typically adopt a simpler routing and flow control scheme called wormhole routing. (Liu, 2003, pp. 499-500)

Wormhole Networks

In a wormhole network, messages are segmented into very small flow control units called flits. In a simple wormhole network, each switch provides only enough buffer space to hold on flit per input link. The buffer is there in order to decouple the input link from the output links.

At each step, only one flit can occupy a link. While a message is using a link, another message that also need the link must wait. So, the transmission of a message may be blocked from starting. When the header i.e. the first flit of a message reaches a switch, the switch selects an output link for the message based on the information provided in the header. If the output link is free at the time, the header moves forward on that link to the next switch, leaving the input link it used to reach the current switch to the second flit in the message. Similarly, the third flit follows, using the link freed by the second flit, and so on. On the other hand, of an output link chosen for a message is in use, the header is buffered and waits at the switch until the output link becomes free. In the meantime, subsequent flitthat have reached upstream switches occupy flit buffers there, one per switch. The associated input links are not available to other messages.

This is the routing phase of message transmission. The routing of a message starts when its header leaves the source processor and completes when the header reaches the destination processor. Hereafter, the message has all the links along the path between its source and destination. Each link is occupied by one of the message’s flits. The flit shifts downstream by one link in each step without intervention of the switches. Thus, the message “worms” its way non-preemptively through the network without being queued at any switch. Its transmission completes when its flit is delivered to the destination processor.

The message delay through the wormhole network is the sum of its routing time and transmission time. The transmission time is the total propagation delay of all links on its transmission path. The time required to route a message depends on the overall network traffic and is the nonpredictable component of message delay. (Liu, 2003, p. 500)

References

Liu, J. W. (2003). Real Time Systems. Pearson Education, Inc. and Dorling Kindersley Publishing Inc.

Schulzrine, H. (2003). RTP: A transport Protocol for Real Time Aplication. Columbia University. Retrieved https://www.ietf.org/rfc/rfc3550.txt july 2003