Internet traffic consists of data sent by different kinds of applications such as web traffic, FTP traffic and real-time multimedia traffic (voice and video). Different applications use different transmission protocols to send their data. FTP and web traffic are sent using TCP protocol. Voice and video are sent using RTP/UDP protocol suite. Sending different kinds of data simultaneously can result in one transmission having negative effect on the other one. It is highly accurate in case of mixing responsive flows such as TCP and nonresponsive flows such as RTP or UDP.
In that scenario RTP/UDP flows tend to suppress TCP flows resulting in disproportional use of bandwidth. TCP senders can be even throttled down by RTP/UDP traffic as RTP/UDP senders do not reduce their transmission speed in time of congestion. This problem is especially relevant as the percentage of the RTP/UDP traffic increases. This problem was named TCP-unfriendliness and TCP-Friendly Rate Control was proposed as a solution. Considering TCP flows, it's reasonable to ask all flows (TCP and RTP/UDP) to fairly share available bandwidth. But, on the other hand, reduction of RTP/UDP transmission rate can cause real-time application to be no longer real time.
From the services point of view, forcing RTP/UDP flows to adapt to rate of TCP flows is unreasonable. Some authors suggest that balance between elastic and inelastic traffic should be achieved not on a per-flow basis but on the aggregate level. Also some work were presented showing that not all of real-time traffic is a threat to TCP traffic.
Elastic and Inelastic Traffic
Elastic traffic is not sensitive to delay. Figuratively speaking, it can spread in time. This kind of traffic is associated with applications that send their data using TCP protocol. They are application such as FTP, WWW and e-mail. They direct to transport protocol a continuous set of data (file, message, e-mail or web page) and the transmission rate of this data depends on transport protocol mechanisms and network conditions.
Because this transmission does not have time borders (e.g. file transfer can last one minute as well as 10 seconds) it doesn't have to meet real time conditions. Because real time conditions don't have to be met, elastic traffic is invulnerable to delay and jitter. It also doesn't have minimum bandwidth requirements (but high throughput is desirable). But it requires correct data transmission, which is achieved by reliable ...