Understanding TCP Behavior for Real-time CBR Workloads
Salman A. Baset, Eli Brosh, Vishal Misra, Dan Rubenstein, and Henning Schulzrinne
Computer Science Department, Columbia University
Problem Statement
TCP delay prediction tool
How does TCP perform for delay-sensitive
applications with CBR workloads such as
Voice or Video?
 Novel stochastic model for TCP delay
 A function of
 Network loss rate
 Round-trip time
 Workload rate and size
In theabsence of losses, w.p (1  p )
 Novel
 Characterizes delay rather than throughput
 Does not assume saturated sender
wi  1

wi 1  
min(r , wi  1)
 TCP is used by lots of applications
 TCP bypasses NAT and Firewall connectivity
restrictions

bi 1  max(0, bi 

Voice over
TCP
Firewall
VoIP client
E.g., Skype
Network
Emulator
`
Fixed RTT 100ms
Delay-sensitive
CBR over TCP
(e.g., VoIP)
Elastic Data
over TCP
(e.g., FTP)
Linux
Windows XP
ACK-vs-byte
counting
ACK-counting
Any
2.6.17.8
supports both
with ‘reno’
ACK-counting
(Vista supports
Byte-counting
during slow-start)
TCP_NODELAY
Enabled
May be
Supported
Supported
Delayed ACK
Disabled during
ACK-counting
May be
disabled
Supported
Not supported
Non-blocking
send
Recommended
May be
Supported
Supported
Rate-halving
Beneficial
Beneficial
Supported
No information
mechanisms
Periodic and random losses
CBR Sender
Linux based
100 packets/s, MSS=1448
TCP Delay (s)
TCP Delay: sender + network + receiver
TCP Overhead: sender + receiver
Delay due to inorder reliable
delivery requirement
0.1
Receiver
18 0.15
12
0.05
Sender
6
Backlog
Segments
in flight
TCP
Rcv
Buffer
Network
delay


rs
wi MSS
0
) if bi  0
if bi  0
w
if bi  0
if bi  0
if bi  0
if bi  0
95% percentile TCP overhead
24
Delay due to backlog
at sender (congestion
window limitation)
0.1
18
12
0.05
6
0.1
0.08
0.06
0.04
0.02
0
0.1
0
0
120
160
200
240
0
Packet Number
TCP
Send
Buffer
0.2
Delay
CWND
0.15

 Obtained via delay prediction tool
 Verified experimentally
Reaction to a triple-dup loss event
24
departingsegs
Delay overhead results
TCP Delay and CWND evolution
 Who got it right for delay-sensitive applications?
Performance Metrics
CBR
Receiver
Experimental results
0.2
arrivingpckts
Notation:
 wi window size at round i
 bi backlog size at round i
 r packet arrival rate in RTT
 s the packet size in bytes
max(0, bi  rs  wi / 2 MSS

bi 1  
max(0, bi  rs  min(r , wi ) / 2 MSS
`
Congestion Window
App type
if bi  0
if bi  0
wi / 2 


wi 1  
min(r , wi ) / 2 
VoIP Client
 Lots of TCP variants out there
w
If a loss indicationis received,w.p 1 - (1  p )
Experimental Setup
0.95 Delay Percentile (s)
Why is it important?
Window and backlog evolution
in congestion avoidance phase
(a) ‘Small’ packet size
of 200 bytes
0
0
100 140 180 220 260
Packet Number
(b) Full packet size of
1448 bytes
10
0.05
Round Trip Time (s)
10
0 10-10
-5
Loss Rate
Rate 50 p/s, packet size 100 bytes, MSS 1000 bytes
A Flow with ‘small’ packet size is less effected by
TCP's window variations than a flow with ‘large’
packet size.
The delay overhead of 'small' packet sized flows
(MSS/10) is lower then 200ms with probability 0.97
for RTTs< 100ms and loss rates<1%
Conclusions and Observations
Ongoing work
 TCP can satisfy the delay constraints of
Delay reduction Heuristics
Idea: reduce sender-side backlog
 Reduce packet size and increase
packet rate
 Proactive sender-side packet drop
Our Contributions
 Novel
delay prediction tool
 Heuristics for reducing delays
a delay-sensitive application over a
wide-range network settings
 The use of smaller than MSS-sized
packets exploits TCP's ACK counting
mechanism and thereby limits the
sender-side buffering due to congestion
window variations
 Compare CBR over TCP delays to
those of UDP in the Internet using
Planet-Lab