TCP-Friendly Window-based Congestion Control (TFWC) is a transport layer congestion control protocol for real-time interactive multimedia streaming applications. TFWC works just like the standard TCP (and its variants) but it can generate much smoother throughput across wide range of network environments, and yet fair to share bottleneck bandwidth when competing with TCP sources.


Typically, real-time multimedia streaming applications prefer a congestion control mechanism that can provide smooth and predictable sending rate while being responsive fast enough to adapt the network changes reasonably well. For these requirements, TCP is generally not considered suitable for those types of applications (especially for inter-active applications), mainly due to its variability and reliability feature. This has led to the development of TFRC, the proposed standard for multimedia streaming applications in Internet Engineering Task Force (IETF), which produces a smoother sending rate while being fair when competing with the standard TCP flows, and also being responsive to the network changes. Short after, there have been a number of literatures that evaluated the protocol's performance, and discussed the possibilities and limitations for the use of the protocol in real situations. All of these works [1, 2, 3, 4, 5] have questioned the initial design intent whether it actually certify the offered features (i.e., smoothness, fairness, and responsiveness), which have known to be "not always".

  • Limitations of Equation
The authors of [5] discussed that the TCP equation itself that TFRC has used bear inherent limitations, resulting in deteriorating the potential benefits that the protocol might have brought.

The authors of [3] identified that the different scheme used for TFRC and TCP, when measuring RTT and RTO, would drive in different behaviors between them, especially during the slow-start phase. With shorter link delay, there is an inclination that TFRC sets smaller RTO values than TCP. This initial gap in sending rate can incite to have different loss rate between TFRC and TCP, which may eventually lead into unwanted or uncontrolled situation.

  • Limitations of being Rate-based
The author of [4] revealed a practical limitation being a rate-based control, such that when RTT is so small (much smaller than the host OS's interrupt timer granularity), there would be a period that the sender produces zero throughput in an extreme case. This ill-reported rate can limit the TFRC's computed rate, resulting in being excessively conservative mode.
  • It is difficult to build the sending rate accurately due to the clocking issues on the host.
  • It is difficult to measure the received rate correctly in a real system, especially at low sending rate, due to late arriving packets.
  • Observation from ns-2 simulation
In ns-2 simulations we have also observed that if a flow traverses a low stat-muxed network link such as a DSL line using drop-tail queue, TFRC source can starve TCP sources. This is because TFRC lacks the fine-grain congestion avoidance mechanism that TCP's Ack-clocking provides, meaning that TFRC can briefly overshoot the available link capacity. This fills the buffer at the bottleneck link and can cause TCP's Ack-clock to decrease the transmit rate, whereas TFRC does not back off so much.

All of the problems above essentially stem from the same basic cause: it is difficult to build a rate-based protocol with a rate that is inversely proportional to the RTT while achieving stability in all conditions.


All of the above issues beg the question why TFRC is rate-based at all. There were two original motivations: (1) TFRC was intended to be usable for multicast, where window-based protocols are not practical (however, this is not relevant to many applications) (2) The intent was that a rate-based protocol would be smoother than a window-based protocol on time-scales of a few RTTs.

On shorter time-scales even rate-based protocols cannot be smooth due to clocking issues on the host, and on longer time-scales the behavior is dominated by the varying loss rate. But to be stable, TFRC had to include a short-term mechanism to back off the rate as the RTT increased, so even TFRC exhibits some short-term variability in rates.

Therefore, we introduce a window-based version of TFRC, which uses a TCP-like Ack-clocking mechanism while apply the same TCP equation, a la TFRC, to directly adjust the window size. Our objective is to remedy the issues discussed above which relate to the combination of rate-based control with the rate being inversely proportional to the RTT. Using a window makes the RTT implicit in the Ack clock, and removing the need to be rate-based makes life much simpler for application writers, as they no longer need to work around the limitations of the OS's short duration timers. 


In this work, we have achieved that TFWC protocol can generate as smooth sending rate as TFRC, and fairer to the competing TCP flows than with TFRC and yet responsive to the sudden network changes. We showed that TFWC is much simpler to implement in a real world application.