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

How does TCP perform for delay-sensitive applications with CBR workloads such as Voice or Video?

Why is it important?

TCP is used by lots of applications TCP bypasses NAT and Firewall connectivity restrictions

Lots of TCP variants out there

Who got it right for delay-sensitive applications?

Performance Metrics

TCP Delay: sender + network + receiverTCP Overhead: sender + receiver

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

Window and backlog evolutionin congestion avoidance phase

TCP delay prediction tool

Novel stochastic model for TCP delay A function of

Network loss rate Round-trip time Workload rate and size

Novel Characterizes delay rather than throughput Does not assume saturated sender

Ongoing work

Delay reduction HeuristicsIdea: reduce sender-side backlog

Reduce packet size and increase packet rate Proactive sender-side packet drop

Compare CBR over TCP delays to those of UDP in the Internet using Planet-Lab

0 if2/),min(,0max(

0 if2/,0max(1

0 if2/),min(

0 if2/1

)1(-1 w.preceived, is indication loss a If

0 if0

0 if)

segs departing pckts arriving

,0max(1

0 if)1,min(

0 if11

)1( w.plosses, of absence In the

ibMSSiwrrsibibMSSiwrsib

ib

ibiwribiw

iw

wp

ibibMSSiwrsibib

ibiwribiw

iw

wp

Conclusions and Observations

TCP can satisfy the delay constraints of 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

95% percentile TCP overhead

(a) ‘Small’ packet size of 200 bytes Rate 50 p/s, packet size 100 bytes, MSS 1000

bytesSegments in flight

Backlog

Network delay

Sender Receiver

TCP Send Buffer

TCP Rcv Buffer

VoIP clientE.g., Skype

VoIP Client

Voice over TCP

Firewall

Our Contributions

Novel delay prediction tool Heuristics for reducing delays

No informationSupportedBeneficialBeneficialRate-halving

SupportedSupportedMay beRecommendedNon-blocking send

Not supported

Supported

ACK-counting

(Vista supports Byte-counting during slow-start)

Windows XP

SupportedMay be disabled

Disabled during ACK-counting

Delayed ACK

SupportedMay beEnabledTCP_NODELAY

2.6.17.8 supports both with ‘reno’

AnyACK-countingACK-vs-byte counting

LinuxElastic Data over TCP (e.g., FTP)

Delay-sensitive CBR over TCP(e.g., VoIP)

App type

mechanisms

No informationSupportedBeneficialBeneficialRate-halving

SupportedSupportedMay beRecommendedNon-blocking send

Not supported

Supported

ACK-counting

(Vista supports Byte-counting during slow-start)

Windows XP

SupportedMay be disabled

Disabled during ACK-counting

Delayed ACK

SupportedMay beEnabledTCP_NODELAY

2.6.17.8 supports both with ‘reno’

AnyACK-countingACK-vs-byte counting

LinuxElastic Data over TCP (e.g., FTP)

Delay-sensitive CBR over TCP(e.g., VoIP)

App type

mechanisms

120 160 200 2400

0.05

0.1

0.15

0.2

TC

P D

elay

(s)

Packet Number

DelayCWND

120 160 200 2400

6

12

18

24

100 140 180 220 2600

0.05

0.1

0.15

0.2

Packet Number100 140 180 220 260

0

6

12

18

24

Con

gest

ion

Win

dow

Network Emulator

CBR Sender

`

CBR Receiver

`Fixed RTT 100ms

100 packets/s, MSS=1448

Periodic and random losses

Linux based

Experimental Setup

Experimental results

(b) Full packet size of 1448 bytes

TCP Delay and CWND evolution

10-10

10-5

100

0

0.05

0.10

0.02

0.04

0.06

0.08

0.1

Loss RateRound Trip Time (s)

0.95

Del

ay P

erce

ntile

(s)

Delay overhead results

Obtained via delay prediction tool Verified experimentally

Delay due to backlog at sender (congestion

window limitation)

Delay due to in-order reliable

delivery requirement

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%

A Flow with ‘small’ packet size is less effected by TCP's window variations than a flow with ‘large’ packet size.

Reaction to a triple-dup loss event