Preparation of Papers in Two-Column Format for the Proceedings of ...

An Improved TFMCC Protocol Based on End-to-End
Unidirectional Delay Jitter
Shumin Yue Yewen Cao
School of Information Science and Engineering School of Information Science and Engineering
Shandong University Shandong University
Jinan, P.R. China Jinan, P.R. China
yueshumin2008@163.com ycao@sdu.edu.cn
Abstract-TFMCC is a representative single rate multicast
congestion control protocol. It uses packet loss ratio as the only
congestion signal and lacks efficient control mechanism for endto-end
unidirectional delay jitter. Multimedia applications have a
high requirement of real-time and stability. It is significant for
multimedia applications to detect congestion in time before the
packet loss occurs in order to reduce delay and delay jitter.
TFMCC is not efficiently suited for the multimedia applications.
In this paper, end-to-end unidirectional delay jitter between the
source and the CLR is used as a forecast congestion signal to
adjust the source sending rate before the packet loss occurs.
Delay, delay jitter and packet loss ratio can be efficiently reduced
by our new algorithm. Our new algorithm improves the stability
of TFMCC protocol and adapts to the real-time multimedia
applications better. Through NS2 Simulation, the results show
that our algorithm brings remarkable performance ameliorate to
average end-to-end delay, average delay jitter and packet loss
ratio on the premise of preserving TCP-Friendliness with TCP
flows.
Keywords-TFMCC protocol, congestion signal, end-to-end
unidirectional delay jitter, stability, real-time, NS2 Simulation
I. INTRODUCTION
Recently, multimedia applications such as audio
conferences and interactive games are becoming increasingly
universal as new Internet services. These applications have
two distinct characteristics: point-to-multipoint and the
requirement of huge bandwidth. Multicast protocol is an
efficient solution for multicast applications for the sake of
saving bandwidth of the bottleneck link. Mostly, multimedia
applications are established on UDP which is a “best-effort
delivery” protocol and has no network congestion control. IP
Multicast [1] applications provide no guarantee for reliable
data delivery, which results in indeterminate network
transmission and unfair competition with TCP flows.
Transmission Control Protocol (TCP) [2] is an end-to-end
congestion control mechanism. It ensures the reliability of the
data delivery 1 and dominates 90% of the current network
traffic. Multicast congestion control has been applied in the
multicast network in order to avoid network collapse and keep
TCP-Friendly with TCP flows when they compete for
bottleneck bandwidth. The design of a reliable multicast
This work is supported by the National Natural Science Foundation of China
under Grant No.60872023, and the Scientific Research Foundation for the
Returned Overseas Chinese Scholars, Education Ministry of China (2007).
___________________________________
978-1-61284-307-0/11/$26.00 ©2011 IEEE
����
congestion control protocol which provides high performance,
scalability, and TCP-Friendliness with TCP flows is a difficult
and primary task.
There are two sorts of multicast congestion control protocol:
single rate protocol and multi-rate protocol. In the single rate
scheme, the multicast source transmits data packets to all
receivers within the multicast session using a single rate and
adjusts its sending rate according to the expected throughput
of the slowest rate receiver (CLR). In the multi-rate scheme,
the multicast source transmits data packets using different
sending rates. Receivers are allowed to join or leave a layer
according to their current available bandwidths. Besides, some
coding techniques are required in the multi-rate scheme. The
multi-rate scheme has better scalability with a series of
sending rates for different receivers but it is difficult to
implement for the multi-rate scheme. The single rate scheme
has an advantage of being simple to implement. Some single
rate multicast congestion control protocols have been
proposed such as TFMCC (TCP-Friendly Multicast
Congestion Control) [3, 4], PGMCC [5] and ORMCC [6]. In
this paper we primarily discuss TFMCC protocol which is an
equation-based single rate congestion control protocol.
TFMCC uses packet loss ratio as the only congestion signal,
which brings high packet loss ratio and results in that TFMCC
can not respond to the network congestion in time before the
packet loss occurs. Besides, TFMCC lacks efficient control
mechanism for end-to-end unidirectional delay jitter, which
results in a high delay jitter, i.e., a bad stability. Some
researches related to the stability of TFMCC have been carried
out. They just focused on reducing fluctuate of the sending
rate [8] or reducing fluctuate of the expected throughput of the
receivers [7] and they did not take the end-to-end delay jitter
into account, besides, congestion condition before packet loss
occurs was always neglected. They could not reduce the
correlative delay and delay jitter for real-time multimedia
applications.
In this paper, an improvement to TFMCC using end-to-end
unidirectional delay jitter as a forecast congestion signal is
presented. This new algorithm enhances the performance of
real-time, stability and has a lower packet loss ratio. The
multicast source calculates the end-to-end unidirectional delay
between the source and the CLR periodically before packet
loss occurs and then estimates the correlative delay jitter as the

forecast congestion signal other than loss event ratio to adjust
the source sending rate. Our new algorithm achieves lower
delay and delay jitter efficiently and a timely response to the
network congestion. It is suited for real-time applications. Our
proposed algorithm will be evaluated via extensive NS2
simulations.
The remainder of this paper is organized as follows: Section
II provides a detailed description of our new algorithm. In
section III, the simulation results between the original
TFMCC protocol and the improved TFMCC-imp protocol are
presented. Finally, in section IV we conclude this paper.
II. IMPROVED TFMCC PROTOCOL BASED ON END-TO-END
UNIDIRECTIONAL DELAY JITTER
TFMCC uses an equation (a model of TCP long-term
steady-state throughput) which is originally derived from the
TCP-Friendly Rate Control protocol (TFRC) [9] to calculate
the expected throughput X tcp of each receiver. The expected
throughput X tcp is a function of the steady-state loss event
ratio p , the round-trip time RTT and the packet size S ,
according to the following equation:
X
tcp
S
�
2p 3p
RTT ( (12 ) p(1 32p
3 8
2
� � ))
Each receiver estimates the loss event ratio p and the
round-trip time RTT . It then calculates the expected
throughput X tcp using equation (1). The receiver with the
lowest expected throughput is elected and declared as the
current limiting receiver (CLR) by the source. Receivers give
feedback to the source based on a feedback suppression
mechanism using randomized timers. The CLR gives feedback
periodically, while the non-CLR receivers send feedback
unless its expected throughput falls below the current sending
rate. The source adjusts its sending rate periodically according
to the expected throughput of the CLR.
The source sending rate is adjusted according to the loss
event ratio p which can be estimated only after the packet
loss occurs. So receivers can not calculate the expected
throughput X tcp before they experience the packet loss. In
TFMCC the source can not obtain the congestion signal before
the packet loss occurs and therefore can not respond to the
network congestion in time, which brings unnecessary packet
loss and a bad performance of response. Besides, the source
only adjusts its sending rate periodically according to the
expected throughput of the CLR and takes no account of the
delay and delay jitter between the source and the CLR which
represent the performance of real-time and stability of the
network respectively. So the initial TFMCC protocol has a
lower stability and a worse performance of real-time.
To resolve the problems mentioned above, an improved
TFMCC is presented using the end-to-end unidirectional delay
jitter as a forecast congestion signal between the source and
(1)
����
the CLR to modify the source sending rate. This scheme
enhances the efficient control of the end-to-end delay jitter
and is suited for the real-time applications perfectly. We
describe the correlative definitions about the end-to-end
unidirectional delay and delay jitter of the improved TFMCC
protocol and then specify the work process of the improved
TFMCC protocol based on the end-to-end unidirectional delay
and delay jitter between the source and the CLR.
A. End-to-End Unidirectional Delay
End-to-end unidirectional delay refers to the transmission
time of the data packet from the source to the receiver. End-toend
unidirectional delay jitter refers to the difference between
two consecutive delays. According to the content of the
feedback packet defined in TFMCC, the source has sufficient
timestamp information to calculate the end-to-end
unidirectional delay and delay jitter between the source and
the CLR. The source uses the calculated delay and delay jitter
to improve the TFMCC protocol. We make some related
definitions about the end-to-end unidirectional delay and delay
jitter of the improved TFMCC protocol in the following part.
In the improved TFMCC protocol, every time the source
receives a feedback packet from the CLR, the current
instantaneous end-to-end delay between the source and the
CLR is calculated by the source:
d _ sam() i �t_ fdb() i �t_ s() i � t_int() i (2)
where, d _ sam() i represents the end-to-end unidirectional
delay between the source and the CLR for the ith
data packet.
t_ fd bi () represents the feedback time of the CLR for the
data packet. t_ s() i represents the sending time of the source
for the ith
data packet. t_int( i ) represents the feedback delay
of the CLR for the ith
data packet after the CLR receives it.
The current smoothed estimate value d _ ave() i of
d _ sam() i is updated as follows:
If no feedback from the CLR has been received before
Else
d _ ave() i � d _ sam() i
(3)
d _ ave() i �(1 �q) �d _ sam() i �q�d _ ave( i�
1) (4)
where, d _ ave( i� 1) represents the smoothed estimate value
of d _ sam( i� 1) for the ( i �1) th data packet. d _ ave() i is
calculated using the method of Exponential Weighted Moving
Average (EWMA). q represents the weighted factor and we
can get better performance when q � 0.7 . The difference
d _ ave() i �d_ ave( i � 1) represents end-to-end unidirectional
delay jitter for the i th data packet.
A congestion judging factor a is then calculated by the
source using d _ ave() i �d _a ve( i � 1) . The source uses a as
the congestion signal before the packet loss occurs:
ith

d _ ave() i �d _ ave( i�1)
a �
1
�( d _ ave( i) �d _ ave( i�1))
2
In the congestion avoidance stage, the source calculate a
modifying factor m ( m �1�a) which is used to modify the
expected throughput X tcp of the CLR. The source uses the
modified expected throughput X 'tcp to adjust the sending rate.
B. Improved TFMCC with End-to-End Unidirectional Delay Jitter
TFMCC protocol has four stages like the unicast TFRC
protocol: slow-start stage, congestion avoidance stage, rate
increase stage and rate decrease stage. After introducing the
end-to-end unidirectional delay and delay jitter, the work
process of the improved TFMCC protocol is as follows: In the
slow-start stage, the source sending rate is increased twice
every RTT and the source just uses the packet loss as the
congestion signal. In the new algorithm the source also
calculates a congestion judging factor a as a congestion
signal every time the source receives a feedback from the CLR.
Once there has a packet loss or a � 0.1 is satisfied, TFMCC
exits the slow start stage and comes into congestion avoidance
stage. In the congestion avoidance stage, the source adjusts its
sending rate according to the expected throughput X tcp of the
CLR periodically. In the new algorithm the source also
calculates a modifying factor m to modify the expected
throughput X tcp of the CLR and adjusts the sending rate using
the modified expected throughput X ' tcp � m* Xtcp
.
According to the work process described above we give the
flow chart of our improved algorithm in TFMCC protocol
using the end-to-end unidirectional delay as follows:
for(every time the source receives feedback from CLR)
{
calculate d _ ave( i) using equation (3) or (4);
calculate the judging factor for congestion:
d _ ave() i �d _ ave( i�1)
a �
1
�( d _ ave( i) �d _ ave( i�1))
2
if (slow start) {
if (packet lost or a � 0.1)
exit slow start;
else
remain slow start;
} else {
calculate the modifying factor: m �1�a; modify the expected throughput using modifying
factor: X ' tcp � m* Xtcp
if ( X 'tcp � current sending rate)
rate increase;
else
rate decrease;
}
}
(5)
����
Notation: If a � 0.1 , there has no congestion. Otherwise,
there has congestion. This can be explained as follows: If the
delay jitter is higher than 10% of the delay, the potential jitter
will occur [10].
III. SIMULATION AND ANALYSIS
A. Simulation Environment
Simulations were carried out using Network Simulation (ns-
2.31). We call our new algorithm TFMCC-imp. The
simulation topology adopted for all simulations is fixed as
illustrated in Fig. 1 which is a typical single-bottleneck
topology. The link between node 0 and node 1 represents the
bottleneck link with a capacity of 2 Mbps and the delay on this
link is set to 20 ms. The other links have capacities of 10
Mbps and the delays on these links are set to 5 ms. Node 2 is
used to transform TFMCC flow (or TFMCC-imp flow) to the
multicast group which is from node m to node n and the
number of multicast receivers is varied from 5 to 30; node 3,
node 4 and node 5 transform TCP flows to node 6, node 7 and
node 8 respectively. Three TCP flows and one TFMCC (or
TFMCC-imp) flow share the bandwidth of a bottleneck link.
The simulation time is 500 seconds.
B. TCP-Friendliness
Fig. 2 shows the TCP-Friendliness of both versions of
TFMCC, i.e., TFMCC and TFMCC-imp. It is observed from
the simulation result that TFMCC-imp obtains a throughput of
about 500kbps like TCP and TFMCC, so it preserves TCP-
Friendliness and shares the bottleneck bandwidth fairly with
TCP flows. Further, it is noticed that the throughput of
TFMCC-imp increases faster than TFMCC in the beginning
and TFMCC-imp gets into steady state earlier than TFMCC.
This can be explained as follows: TFMCC-imp protocol can
detect the network congestion signal earlier and adjust its
sending rate to a proper value in time according to the network
congestion conditions by using the end-to-end unidirectional
delay jitter as a forecast congestion signal before the packet
loss occurs.
C. Average End-to-End Unidirectional Delay
Fig. 3 shows the average end-to-end unidirectional delay
between TFMCC and TFMCC-imp with a growing number of
receivers from 5 to 30. It is observed from the simulation
results that TFMCC-imp has a lower average end-to-end
unidirectional delay than TFMCC protocol by using the endto-end
unidirectional delay jitter as a forecast congestion
signal before the packet loss occurs. This is because TFMCCimp
uses the end-to-end unidirectional delay jitter to adjust
congestion condition and control the source sending rate,
which can efficiently reduce the average end-to-end delay
according to the achieved network congestion signal. Because
of the lower end-to-end delay, TFMCC-imp is better suited for
real-time multimedia applications with a high requirement of
real-time.

D. Average End-to-End Unidirectional Delay Jitter
Fig. 4 shows the average end-to-end unidirectional delay
jitter between TFMCC and TFMCC-imp with a growing
number of receivers from 5 to 30. It is observed that TFMCCimp
has a lower average end-to-end delay jitter than TFMCC
by using the end-to-end unidirectional delay jitter as a forecast
congestion signal before the packet loss occurs. This can be
explained as follows: TFMCC-imp which uses the end-to-end
unidirectional delay jitter can efficiently smooth the end-toend
delay jitter between the source and the CLR by adjusting
the source sending rate according to the network congestion
conditions achieved by the delay jitter. Obtaining a better
performance of low delay jitter, TFMCC-imp is better suited
for the multimedia applications which have a high requirement
of stability.
Throughput(Kbps)
700
600
500
400
300
200
100
Figure 1. Network topology used for the simulations
Throughput
TCP
TFMCC
TFMCC-imp
0
0 100 200 300 400 500
Simulation time(s)
Figure 2. Comparison of TCP-Friendliness of TFMCC and TFMCC-imp with
3 TCP flows
����
Average end-to-end delay(s)
185
184
183
182
181
Average end-to-end delay
TFMCC
TFMCC-imp
180
5 10 15 20 25 30
Simulation time(s)
Figure 3. Average End-to-End Unidirectional Delay of TFMCC and TFMCCimp
with a growing number of receivers
Average end-to-end delay jitter(s)
34
33
32
31
30
29
Average end-to-end delay jitter
TFMCC
TFMCC-imp
28
5 10 15 20 25 30
Simulation time(s)
Figure 4. Average End-to-End Unidirectional Delay Jitter of TFMCC and
TFMCC-imp with a growing number of receivers
E. Average Packet Loss Ratio
The average packet loss ratio between TFMCC and
TFMCC-imp is evaluated. It is observed that the average
packet loss ratio of TFMCC-imp is 0.52% and the average
packet loss ratio of TFMCC is 0.59% when competing with 3
TCP flows. So the average packet loss ratio of TFMCC-imp
has improved by about 11.9% at the same network
circumstance. This is because TFMCC-imp can respond to the
network congestion conditions and adjust its sending rate in
time by using the average delay jitter before packet loss occurs.
IV. CONCLUSION
This paper presents an improved algorithm of TFMCC
protocol. TFMCC is a single rate MCC protocol based on a

TCP long-term equation. The improved algorithm is based on
the end-to-end unidirectional delay jitter between the source
and the CLR periodically. Simulation results show that using
this new algorithm we achieve remarkable improvements in
TCP-Friendliness, packet loss rate, real-time and stability of
TFMCC. More studies should be done in the future to improve
the performance of multicast congestion control protocols in
order to suit the multimedia applications better.
REFERENCES
[1] S. Deering, “Host extensions for IP multicasting”, RFC1112, Jan. 1989.
[2] P. Gevros, J. Crowcroft, and S. Bhatti, “Congestion control mechanisms
and the best effort service model”, IEEE Network, 15(3):16-26, 2001.
[3] J. Widmer, and M. Handley, “Extending equation based congestion
control to multicast applications”, in Proc. of ACM SIGCOMM ’01,
2001.
����
[4] J. Widmer, R. Denda, and M. Mauve, “A Survey on TCP-Friendly
Congestion Control”, IEEE Network, 15(3), pp.28-37, May/Jun. 2001.
[5] L. Rizzo. pgmcc: A TCP-friendly single-rate multicast congestion
control scheme. In Proc. ACM SIGCOMM, pp.17 – 28, Stockholm,
Sweden, August 2000.
[6] Jiang Li, S.Kalyanaraman, “ORMCC: A Simple and Effective Single
Rate Multicast Congestion Control Scheme”, Proceedings of IEEE
INFOCOM, 2003.
[7] Kammoun, W., Youssef, H., “Improving the Performance of End-to-End
Single Rate Multicast Congestion Control”, IEEE Symposium on
Computers and Communications, 2008, ISCC 2008, pp: 1128.
[8] Haiyuan Ma, Xiangru Meng, Li Zhou, Huan Li, and Xiaomin Zhang,
“Fuzzy-Logic-Based Rate Adaption Scheme for TFMCC”, International
Conference of Networking and Digital Society, 2009, ICNDS ’09,
Volume 1, pp: 238-241.
[9] S. Floyd, M. Handley, J. Padhye, and J. Widmer, “Equation-based
congestion control for unicast applications”, In Proc. ACM SIGCOMM,
pages 43 – 56, Stockholm, Sweden, Aug. 2000.
[10] Yang Chen, Chunming Qiao, “Proportional Differentiation A Scalable
QoS Approach” IEEE Communication Magazine [J] June 2003 52-58.