Multimedia Protocols
Multimedia applications over the internet are often sensitive to delay, but can tolerate some packet loss (which would cause concealable glitches). Data of this type generally falls into three classes of applications:
- Streaming. Clients request files from servers and pipeline reception over the network. Can be a delay from request to display start, and user can control operation with regular pause/resume/rewind options.
- Unidirectional Real-Time. Similar to existing understanding of TV and Radio, non-interactive user can just listen or view but not control the content.
- Interactive Real-Time. Two-way real time communication, for example voice or video conference. Much more stringent delay requirements because of real-time human nature.
The TCP/UDP/IP Suite provides best-effort but no guarantees when it comes to multimedia content, if load increases then performance can rapidly deteriorate. To mitigate this effect, UDP should be used over TCP, data should be compressed to suit available bandwidth and content should be buffered to avoid jitter. However, more fundamental changes may be needed to the protocols used - resources should be more closely monitored and differntiated services can be introduced which prioritise traffic according to class.
Streaming
As the access to high-speed internet grows there is a growing demand for web streaming. Real-Time Protocol (RTP) sends segmented audio/video content over TCP or UDP. The Real-Time Streaming Protocol (RTSP) can provide user-interactive control, with a helper application displaying content and providing user-options.
To stream a file from a web server there are two approaches:
- The browser reuests the object(s) from the web server and after their reception passes them to the player for display. There is no pipelining here.
- Alternatively a direct connection between the player application and the server can be established, the web browser only passes a meta file containing details of the server to the player. This allows a better tailoring to streaming (such as the use of UDP if desired).
The RTSP uses two connections, one for the media stream and one for control messages. TCP or UDP may be used for the control connection.
Voice Over IP (VoIP)
Coded Voice information is encapsulated into a UDP packet at a rate usually around 8 KB/s, sending a 160Byte packet and header every 20 ms or so. Upto a 20% loss is tolerable, and whilst TCP would eliminate this it would come at massive bandwidth cost.
Since correct packet order must be maintained to avoid jitter, delayed packets can simply be ignored by the reciever. Timestamps and sequence numbers on packets, which are delayed before being ordered at each end can also aid this. Delay greater than 400ms is unacceptable.
Forward Error Correction (FEC)
Forward Error Correction is a technique to reduce the effect of loss (packets never arriving or arrivign too late). A simple FEC scheme adds redundant chunks made up of XOR or a group of n chunks, so there is a redunancy 1/n and lost chunks can be reconstructed if needed.
Mixed quality streams are used to include redundant duplicates of chunks but in a lower quality so upon loss playout is still available but in a lower quality.
Alternatively, data may be interleaved - which has no redundancy but means partially filled chunks can be displayed upon loss.
Real-Time Protocol (RTP)
Typically running over UDP this protocol has the additional header fields:
- Payload Type: Type of encoding, MPEG2, PCM, etc.
- Sequence Number: Used to detect packet loss.
- Timestamp. Sampling instant of the first byte in the packet
- Synchronisation Source Identified (SSRC). An ID for the source of the stream.
Real-Time Control Protocol (RTCP)
This protocol specified report packets exchanged between sources and destinations of multimedia information. These reports may be reciever reception, sender and source description and contain statistics such as the number of packets sent, packet loss, jitter etc and are used to modify sender transmission rates or for diagnostics. RTCP reports need to be scheduled to not increase network load too much, interval between reports can be adjusted based on number of participating receivers.
Quality of Service (QoS)
Work is in progress on ways to improve internet protocols beyond "best effort" and provide some assurance for quality of service. The principles of this are:
- Classifiying packets so routers can treat them accordingly (i.e. priority to audio over file shares)
- Isolation/Protection should be given between classes, they should be marked, scheduled and policed.
- If one class does not use its allocation, it should not be wasted and resources should be used as efficiently as possible.
- Network needs to be able to block traffic beyond its capacity (call admission)
Data can be scheduled in a number of ways, such as FIFO, priority queuing, round robin and weighted fair queuing. It can be policied by monitoring the average rate, peak rate and burst size of transmissions - this can take place through a token bucket mechanism.