*** This work is supported by Polish Government under Grant No. N517 012 32/2108 (years 2007-2009).

__________________________________________

* Kielce University of Technology.

** AGH University of Technology.

*** This work is supported by Polish Government under Grant No. N517 012 32/2108 (years 2007-2009).

Agnieszka CHODOREK*

Robert R. CHODOREK**

APPLICABILITY OF TCP-FRIENDLY PROTOCOLS FOR REAL-TIME MULTIMEDIA TRANSMISSION***

TCP-friendly protocols behave under congestion like TCP. This behavior introduces potential architectural conflict between a transport protocol and real-time multimedia. The article discusses this conflict and shows applicability of TCP-friendly protocols for real- time multimedia transmission. The discussion is illustrated by simulation results carried out in Berkeley’s ns-2 environment.

Keywords: TCP-friendly protocol, congestion control, multimedia

1. INTRODUCTION

It is commonly know, that RTP and UDP transport protocols are not TCP- friendly. It means, that presence of RTP/UDP or UDP transmission causes strong degradation of competing TCP flows. The opposite phenomenon – TCP-friendless – is defined as follows: “We say a flow is TCP-friendly if its arrival rate does not exceed the arrival of a conformant TCP connection in the same circumstances” [1].

Some authors believe, that TCP-like congestion control, added to a real-time protocol, will be effective cure for this “illness” of modern networks. Protocols, which implement TCP-friendly congestion control, are called “TCP-friendly protocols”. The definition of the term “TCP-Friendly Protocol (System)”, given in the “Encyclopedia of Internet Technologies and Applications” [2] goes: TCP- Friendly Protocol (System) is “a protocol (system), which applies TCP-like congestion control. TCP-friendly protocols (systems) directly apply TCP’s congestion control mechanism or emulate it using the TCP throughput equation.

The main properties of TCP-friendly protocols (systems) are avoidance of TCP

connections collapse and fairness toward competing flows.”.

TCP-friendly protocols are applying on modern networks mainly because the TCP protocol do not support multicast and it is not suitable for real-time multimedia. In facts, there is a deep architectural conflict between TCP’s control and real-time multimedia transmission. The main reasons of this conflict are:

– elastics nature of traffic generated by the TCP protocol, while real-time multimedia traffic is inelastic in nature,

– optimization of the TCP protocol’s mechanisms for unicast transmission, while real-time multimedia transmission, typically, is carried out using multicast technologies,

– one of the TCP’s features is equality for competing TCP flows, while real- time multimedia have strictly defined target bit rate, so throughput of multimedia transmission shouldn’t be limited by a transport protocol,

– the TCP has window-based flow control and congestion control mechanisms, while real-time multimedia transmission cannot be window controlled,

– reliable TCP transmission is based on retransmissions, while real-time information shouldn’t be retransmitted.

TCP-friendly transport protocols implement TCP-like congestion control and, as a result, behave under congestion like the TCP. Therefore, the architectural conflicts between the TCP’s control mechanisms and real-time multimedia transmission can be a potential source of conflicts between TCP-friendly protocol and real-time multimedia. The aim this paper is to discus, whether TCP-like congestion control affects TCP-friendly protocol’s ability for carrying real-time multimedia traffic. Because TCP-friendly transport protocols carried multimedia streams usually don’t implement both flow control and retransmission based error control (forward error control sometimes is used), these problems will not be taken into consideration.

This paper is organised as follows. Section 2 discusses the conflict between inelastic nature of streaming media and elastic nature of TCP’s traffic and its influence on TCP-friendly multimedia transmission. In Section 3, the problem of unicast-optimized mechanisms is presented. Section 4 shows problem of equality towards competing TCP flows. Section 5 summarizes the discussion.

2. INELASTIC VS. ELASTIC NATURE OF TRAFFIC

The real-time multimedia stream is inelastic in nature. It means, that

transmission cannot be both “stretched” or “shrunken” in the time. As an example,

the transmission of one-hour-video should last for one-hour. If the transmission

lasts for more than one-hour (e.g. a few hours), it will be impossible to preserve

real-time character of the stream. The video cannot be playback at the rate of its

generating (or recording). The “stretch” of transmission causes decreasing of video

frame rate (sometimes to unacceptable level) or discontinuous playback.

If the transmission lasts for less than one hour (situation possible only in the case of pre-recorded video – e.g. Video on Demand service), real-time playback will request large buffers for buffering video frames. However, according to the Digital Audio-Visual Council (DAVIC), large buffers are not recommended for set-top-boxes for home usage. It’s worth remarking, that small buffers, used for cancellation of small fluctuation of throughput, are recommended. The other solution – faster playback, according to achieved throughput – gives effects similar to fast rewind and is not acceptable by users.

The TCP traffic has elastic nature. It means, that transmission can be

“stretched” or “shrunken” in the time. As an example, transmission of a 4.7 GB data file (e.g. DVD disc image) can last for one hour, as well as for 5 minutes or a few hours. In contrast to inelastic, streaming traffic, all these durations of transmission are usually acceptable (although transmission, which last for a few hours can be irritable for a typical user).

To achieve elastic character of TCP’s traffic, TCP protocol’s mechanisms flexible control TCP flow, continuously increasing and decreasing bit rate. So:

– the flow control mechanisms limits bit rate according to instantaneous receiver’s ability of absorption of transmitted data,

– the congestion control mechanisms limits bit rate according to instantaneous network conditions,

– the error control mechanisms will decrease bit rate if small windows and large error rates suspend a transmission (transmission is resumed after error correction).

Because real-time multimedia stream cannot be either retransmitted nor flow controlled, TCP-friendly protocols used for multimedia transmission typically don’t implement flow control and error control mechanisms. However, the TCP- like congestion control introduces to TCP-friendly protocols TCP-like characteristics of changing of instantaneous throughput. As a result, such protocols behave under congestion like TCP. From competing TCP flows point of view, this feature is a great advantage of TCP-friendly protocols. For multimedia streams point of view, it can lead to unexpected large fluctuations of bit rate, which can’t be eliminated by small buffers installed in set-top-boxes.

An example of this problem is depicted in Fig. 1. In the figure, the TCP- Friendly Rate Control (TFRC) protocol [3] conveys variable bit rate (VBR) video stream. Experiments were carried out using an event-driven ns-2 simulator [4], developed in U. C. Berkeley. As the video stream, Parking-Cam MPEG-4 trace (a video from static camera, which film the parking) was used. It is one of many video traces, which are publicly available at the Arizona State University site (URL: http://trace.eas.asu.edu/TRACE/ltvt.html). Statistical properties of video traces can be found in [5]. Experiments were carried out both in congested and non-congested environments. The congested environment is characterized by 5%

packet error rate (PER), while PER=0% denotes non-congested environment.

0 500000 1000000 1500000 2000000 2500000 3000000

5 6 7 8 9 10 11 12

Time [s]

T h ro u g h p u t [b /s ] .

PER=0%

PER=5%

Fig. 1. Instantaneous throughput of the TFRC flow depending on packet error rate (PER).

Instantaneous throughput of the TFRC protocol depending on packet error rate (Fig. 1) shows, that in non-congested environment the TFRC preserves real-time character of VBR traffic. In the case of congested environment, TCP-like congestion control causes smoothing of VBR traffic. If congestion is large enough, it can lead to extension of transmission time. In Fig. 1., relatively low congestion (packet error rate PER=5%) extends transmission time by 20%.

3. OPTIMIZATION FOR UNICAST TRANSMISSION VS. MULTICASTING

Real-time multimedia transmission usually is carried out using multicast technologies. These technologies are used both for typical multimedia broadcast services (as Internet television) and for unicast in nature multimedia services (as Internet telephony). From the other side, TCP mechanisms are optimized for unicast transmission and this optimization is a main obstacle to use the TCP for multicasting [6]. Unfortunately, optimization of TCP’s congestion control for unicasting can be mapped onto TCP-friendly protocols. As a result, TCP-friendly protocols can be weakly suitable for multicasting.

Suitability of a transport protocol for multicast transmission can be observed as:

– ability for serve large multicast group (so-called “scalability”), – ability for control heterogeneous environment.

Typically, scalability of multicast transport protocols is limited by phenomenon

of implosion of feedback information. In close-loop systems, reception of a data

packet (which is sent from a sender to receivers) generates a feedback (packets or

reports, which are send from receivers to the sender). Because data packets are delivered to many (tens, hundreds, thousands) receivers, a sender will receive many (tens, hundreds, thousands) feedbacks per one packet sent.

Open-loop systems (without feedback) are fully scalable. Their scalability is equal to the scalability of IP network. Close-loop systems, usually, have mechanisms that limit number of feedback messages and, as a result, increase scalability toward large multicast groups.

Although TCP-friendly transport protocols use close-loop congestion control, they are usually characterized by good scalability toward large multicast groups.

Such protocols, as TCP-Friendly Multicast Congestion Control (TFMCC) [7][8]

and PGMCC [8][9], are built in, mapped from the TCP, sender-driven manner.

TFMCC and PGMCC limits number of feedbacks thanks to a special, worst-case receiver. It is a receiver, which works in the worst-case conditions (large congestion) and sends feedbacks on behalf of multicast group.

The Wave and Equation Based Rate Control (WEBRC) protocol [8][10] is build according to, dedicated to multicasting, receiver-driven architecture. The protocol limits number of feedbacks by transfer of close-loop control from the transport layer to the network one. Signaling information, both congestion notification (either losses of IP datagrams or ECN signaling) and signal of changing transmission rate (here: join and leave multicast group) are carried using protocols of network layer (the IP, the IGMP or the MLD, and multicast routing protocols).

As a result, scalability of the WEBRC is close to scalability of open-loop system.

In the case of heterogeneous environments, different branches of delivery tree are characterized by different levels of congestion and (or) different throughput of links. Because the sender-driven architecture is unicast-oriented, it is weakly suitable for heterogeneous environment. For example, the TFMCC and the PGMCC avoid congestion using (sender)-(worst-case receiver)-(sender) control loop. As a result, the most congested branch limits transmission rate in the multicast delivery tree.

The receiver-driven architecture is multicast-oriented and is suitable for heterogeneous environments. The architecture avoids congestions using node-receiver-node control loops. As a result, there is N independent control loops on the delivery tree (where N is a number of receivers – e.g. WEBRC receivers) and transmission rate is controlled independently in each branch of the tree.

4. EQUALITY TOWARDS COMPETING TCP FLOWS

One of the most important properties of TCP transmission is equality towards

competing TCP flows. It means, that all competing TCP flows, transmitted in the

same circumstances, equally share bandwidth of a bottleneck link.

Let B be a bandwidth of a bottleneck link and N be a number of TCP flows.

Each TCP flow achieves throughput of:

N

T _i = B (1)

where T _i denotes a throughput of i ^th TCP flow, i = 1 , 2 , K N .

This equality towards competing flows is usually called “fairness”. The measure of fairness is the fairness coefficient F, usually defined as follows [2]:

( )

1

1 2 2

1

1 ⁻

=

=

 

 



⋅ 

 

 



=  ∑ ∑ ^N

i i N

i

i T

N T

F (2)

The problem of equality towards competing TCP flows appears, when elastic TCP traffic competes for bandwidth with inelastic, streaming traffic. Stream traffic is rate limited and requires real-time transmission. Thus, it shouldn’t be limited in the way, which disables protection of real-time character of transmission. In our opinion, in such situation, equality shouldn’t be equated with fairness.

Let’s assume, that 2.5 Mb/s constant bit rate (CBR) streaming traffic (e.g. live video) competes for 10 Mb/s bandwidth with N TCP flows. Because CBR traffic is able to utilize only ¼ of available bandwidth, equality is possible only in the case of N=3 TCP flows. If N=1 or N=2, the assumption of equality gives utilization of the link at the level of, respectively, 50% and 75%. Of course, the congestion control mechanism implemented in the TCP causes, that real TCP flows always utilize all available bandwidth (here: 7.5 Mb/s) and transmission isn’t fair in the sense of equality.

If N>3, there is impossible to achieve both equality towards competing flows and real-time transmission of inelastic CBR traffic. The assumption of equality forces now, that the CBR traffic must utilize less than ¼ of the bandwidth of the bottleneck link. The achieved throughput must be less than target bit rate of the source of the CBR traffic (2.5 Mb/s), so network is not able to preserve real-time conditions for CBR transmission. In this situation, assumption of equality can cause:

– packet losses – in the case of real-time transport protocol (RTP/UDP or UDP) used for CBR transmission,

– longer transmission time, than supposed (here: duration of video) – in the case of TCP protocol used for carrying multimedia.

It’s worth remarking, that the same situation will occur always, if target bit rate of inelastic traffic exceeds a half of a bandwidth of bottleneck link.

The problem of equality is observed in the case of TCP-friendly transport

protocols, which carry multimedia traffic and compete for bandwidth with TCP

flows or (and) other TCP-friendly flows. Because TCP-friendly transport protocol

behaves under congestion like the TCP, all connections equally share available

bandwidth, independently on real-time requirements of multimedia traffic. To preserve real-time character of multimedia stream, it is assumed, that TCP-friendly protocol should be “reasonably fair”, i.e. should share bandwidth with other connections in a “reasonably equal” way.

0 200000 400000 600000 800000 1000000 1200000

0 1 2 3 4 5 6 7 8 9 10

No. of TCP flows

T h ro u g h p u t [b /s ] .

Fig. 2. TFRC throughput as a function of number of TCP flows.

The “reasonably fair” behavior of TCP-friendly protocol reduces, but not eliminate, the problem of equality. In the Fig. 2., the VBR (Parking-Cam MPEG-4 trace) over TFRC transmission competes for bandwidth (3 Mb/s) with N TCP flows. Target bit rate of the VBR stream is equal to 0.987 Mb/s. If VBR transmission is carried out in dedicated link (N=0), throughput of the VBR stream is equal to its target bit rate. In non-congested environment (N=1), there is no conflict between the principle of flows’ equality and real-time requirements of VBR stream. As a result, the VBR stream still is able to achieve throughput equal to its target bit rate. If N=2, all 3 transmissions should equally share throughput of the link. However, the “reasonably fair” TCP-friendly transport protocol isn’t as aggressive as TCP, so throughput of the TFRC is only close to target bit rate of the VBR stream. In lightly congested environment (N=3), the TFRC isn’t able to preserve real-time character of transmission. If congestion grows up (N>3) we’ll observe collapse of real-time transmission.

5. CONCLUSIONS

TCP-friendly protocols implement TCP-like congestion control. Thanks to this mechanism TCP-friendly protocols avoid collapse of competing TCP connections.

From the other hand implementation of TCP-like congestion control make new

challenges for multimedia transmission. Real-time requirements, multicast

transmission in heterogeneous environment, fairness toward competing flows still remains only partially resolved issues.

REFERENCES

[1] Floyd S., Fall K.: Promoting the Use of End-to-End Congestion Control in the Internet. IEEE/ACM Transactions on Networking, August 1999.

[2] Freire M., Pereira M. (ed.): Encyclopedia of Internet Technologies and Applications.

IGI Global. Hershey – New York, 2008.

[3] Handley M., Floyd S., Padhye J., Widmer J.: TCP Friendly Rate Control (TFRC):

Protocol Specification. RFC 3448. January 2003.

[4] Fall K., Vradhan K.: The ns Manual. http://www.isi.edu/nsnam/doc/ns_doc.pdf [5] Fitzek F.H.P., Reisslein M.: MPEG-4 and H.263 Video Traces for Network

Performance Evaluation. IEEE Network, vol. 15, no. 6. November/December 2001.

[6] Miller C.K.: Multicast Networking and Applications. Addison-Wesley, Reading 1999.

[7] Widmer J., Handley M.: „TCP-Friendly Multicast Congestion Control (TFMCC):

Protocol Specification”. RFC 4654. August 2006.

[8] Chodorek A., Chodorek R.R., Pach A.R.: Dystrybucja danych w sieci Internet.

WKŁ, Warszawa 2007.

[9] Rizzo L., Iannaccone G., Vicisano L., Handley M.: „PGMCC single rate multicast congestion control: Protocol Specification”. INTERNET-DRAFT, Work in progress, 2004 . < draft-ietf-rmt-bb-pgmcc-03.txt>.

[10] Luby M., Goyal V.: „Wave and Equation Based Rate Control (WEBRC) Building

Block”. RFC 3738. April 2004.