Packet Transfer

With respect to packet transfer, interactive real-time streaming applications have a choice of transport mechanisms, packet sizes and packet transmission techniques that are consid- ered here.

Choice of Transport Protocol

Among current transport protocols in the Internet, namely UDP (see section 2.2.1) and TCP (see section 2.2.2), the former should be used when real-time behavior is required. According to the discussion in section 2.2.4 TCP has several drawbacks for use with time- critical traffic. First, to achieve the reliability provided by TCP, retransmission and buffer- ing are unavoidable. Both techniques, however, introduce additional and intolerable delay. Second, real-time media streaming applications need to control their transmission rate rather than leaving this responsibility to a transport protocol that is not aware of QoS. The slow start algorithm, for example, prevents applications that use TCP from transmit- ting with the data rates dictated by the live media sources.

As a result current real-time streaming applications use primarily the simple connection- less protocol UDP as their transport protocol. It allows application to freely control their transmission rate. Moreover, if real-time streaming applications want to benefit from the multicast capabilities of the MBone or IPv6 for group communication, they are currently limited to the use of UDP as their transport protocol.

In the case of real-time streaming the streaming mechanism of choice is currently RTP- on-UDP (see section 2.2.3). RTP on top of UDP adds useful streaming information, such as timestamps, session id, sequence numbers, etc., to the data packets. RTP’s feedback channel, namely RTCP, can be used to send QoS information back to the sender. The QoS feedback is especially valuable if adaptation (see also section 3.1.3) is deployed within the sender applications.

Packet Size

Besides the appropriate choice of transport protocol the packet size used to transmit media streams plays an important role with respect to the end-to-end transmission delay.

In the case of audio or video streaming the payload size is usually a multiple of the media frame size. Audio, for example, is read from the audio device in chunks called audio frames. The number of audio samples contained within an audio frames depends on the device configuration. If the end-to-end delay must be minimal, as in the case of interactive real-time applications, the frame size should be small and the payload should encompass as few frames as possible in order to minimize the packetization delay. Typical live audio applications use frames that encompass 20 or 40 ms of audio data.

The F rameSize is determined by the audio format captured from the sound device. Equa- tion 3.1 shows how to calculate the F rameSize in general. For example, the encoding of

40 ms of 4 kHz monophonic audio1 in 16 bit samples results in a F rameSize of 640 bytes.

3.1. APPLICATION LAYER QOS 75

F rameSize = Channels× SampleSize × SampleRate × T ime (3.1)

The packet payload size is determined by the number of frames sent per packet and the compression or encoding scheme (see equation 3.2). For example, if we consider packets carrying GSM encoded audio data of one mono, 16 bit PCM frame, the payload size results into 65 bytes.

P ayloadSizeGSM = F rames× (CompressionRate × F rameSize) (3.2)

In general, if sophisticated compression algorithms such as GSM, CELP, MPEG, etc., are used to encode the media data, a payload size of only a few media frames is very small. Transferring data packets with a payload size of size less than 100 bytes seems to be inefficient considering that the packet headers in the case of UDP/IP or RTP/UDP/IP transport is already of great size. Equation 3.3 presents the formular to calculate the packet overhead. Overhead = HeaderSize P acketSize =
P rotocolsSize(Header)

P rotocolsSize(Header) + Size(P ayload)

(3.3)

Table 3.1 shows the packet overheads above the link layer of one mono 16 bit PCM frame using uncompressed and GSM encoded audio. This illustrates that the overhead is highly dependent on the transport and application protocols used. Although the packet overhead for small audio packets is very high, the price must be paid if the end-to-end delay must be minimal.

Transport Total PCM GSM

Mechanism HeaderSize P ayloadSize Overhead P ayloadSize Overhead

UDP/IPv4 28 bytes 640 bytes 4% 65 bytes 30%

RTP/UDP/IPv4 44 bytes 640 bytes 6% 65 bytes 40%

UDP/IPv6 48 bytes 640 bytes 7% 65 bytes 42%

RTP/UDP/IPv6 64 bytes 640 bytes 9% 65 bytes 50%

Table 3.1: Packet Overheads of different Audio Encodings and Transfer Mechanisms

To minimize Overhead, or in other words to maximize the network utilization, research in

the area of header compression [D+98b] suggests to transmit only the header information

subject to changes (for example, sequence numbers, timestamp, checksum, etc.). Thus, the packet Overhead can be highly reduced.

Traffic Shaping

Another technique used to improve transmission quality with respect to packet transport is called traffic shaping. The general principle of traffic shaping is to alter the traffic characteristics of the outgoing stream of packets (or cells) on the virtual connection in order to optimize the use of network resources.

In the past traffic shaping played an important role in the research of ATM cell switching. The main schemes proposed by the ATM Forum and ITU are based on the Generic Cell Rate Algorithm and are associated with the Constant Bit Rate (CBR) and Variable Bit Rate (VBR) services.

In the Internet, as it is perceived today, packet losses are of bursty nature [B+97a] due

to queue overflows in end systems or intermediate routers. Therefore, applications for live media streaming should shape the outgoing stream of packets such that the data packets are transmitted isochronously over time rather than in bursts. Although fewer packet losses are expected when applications apply traffic shaping to their data traffic, traffic shaping within network nodes is much more effective.