An Empirical Model of TCP Performance

Allen B. Downey

Olin College of Engineering

1

TCP Performance

Goal: model and predict transfer times.

� Understand TCP performance

• Improve TCP?• Improve the network?

� Interactive applications.

• Predict duration of downloads.• Select mirror site.

� Distributed applications.

• Resource selection.• Scheduling.

2

Goals

Complementary questions:

� What do we need toknow about anetwork path?

� What can wemeasure about anetwork path?

Complementary goals:

� Maximize accuracy. � Minimizemeasurement.

3

Two approaches

� History-based.

• Pro: Good statistical description.• Con: Availability of data?

• Passive: Might not have seen what you need.• Active: Obtrusive?

� Model-based.

• Pro: small measurements ⇒ parameters ⇒

model ⇒ predictions• Con: single-value predictions.• Con: incomplete models, so far.

4

TCP Models

� Several models for mice (never leave slow start).

� Several models for elephants (ignore slow start).

� For medium size (bdp < size < 10bdp), performancedepends on slow start and steady state.

� bdp commonly 4 KB – 128 KB.

� Maybe 40% of TCP transfers are in this range.

5

Hybrid model

� Explicit model of slow start.

� History-based prediction of steady state throughput.

ss0 ss1 ss2 ssn

ca

6

Model parameters

So what do we need to know?

� State transition probabilities.

� Distribution of rtt.

� cw1, cw2, cw3 ...

� Distribution of steady-state throughput.

Can we measure these parameters?

7

Measurement

� Application-level HTTP timing (instrumented wget).

• Pro: easy to implement.• Con: some timing inaccuracy, lost information.

8

Timing chart

0 100 200 300 400time (ms)

0

20

40

60

80

100

siz

e (

10

00

B)

server 7 timing chart� Plot bytes read

vs. time.

� Immediately, wecan estimate rtt,cw, bw and bdp.

� And we can inferTCP state.

9

Estimating parameters

� Divide timing chart into rounds.

� Measure window size for each round.

� Pattern match on window sizes:

• 2, 4, 8, 16, 32 ...• 2, 4, 6, 4, 5, 6 ...• 2, 4, 6, (long pause) 11, 6 ...• 3, 6, 12, 15, 15, 15 ...• 3, 6, 12, 51, 17, 63 ...

10

Measurement

� Measurements:

• 100,000 byte transfers.• 100 transfers, with 100s between.

� HTTP downloads:

• 2 URLs provided by collaborators.• 11 URLs culled from proxy cache logs.

� Diverse network paths:

• rtt from 7 to 270 ms.• bw from 0.350 to 100 Mbps.

11

Window sizes

0 20 40 60 80measurement

0

10

20

30

40

observ

ed w

indow

(packets

)

server 7 window sizes

4321

� This is the sortof thing Iexpected.

� Too bad it’s theexception.

12

Window sizes

0 20 40 60 80measurement

0

5

10

15

observ

ed w

indow

(packets

)

server 3 window sizes

4321

� cw2 issometimes 3,sometimes 4.

� cwn+1 is2 · cwn − m,where m is0, 1, 2, ...

� 10 out of 13 aresimilar.

13

Non-deterministic slow start

� Partial explanation in the paper.

� Putting the “empirical” in “empirical model”.

� Models that omit this behavior can’t work forshort–medium transfers (2–5 rounds of slow start).

14

Estimating Parameters

� R: Distribution of rtt.

� W : Distribution of window size.

� T : Distribution of throughput.

� State transition probabilities.

ss0 ss1 ss2 ssn

ca

15

Generating predictions

Monte Carlo simulation of finite state model:

1. Start at ss0.

2. Choose a state transition at random.

3. If in slow start, choose rtt from R and cw from W.

4. If in congestion avoidance, choose throughput from T.

5. Update total time and total data transmitted.

6. If total data > size, return total time.

7. Otherwise go to step 2.

16

Validation

� Randomly partition 2 datasets of 50 measurements.

� Estimate parameters and generate distributions fromone subset.

� Compare to actual times from other subset.

� Agreement indicates that the model is sufficientlydetailed, and that the estimated parameters areconsistent.

17

Example #1

62 119 231 447 866x (ms)

0.0

0.2

0.4

0.6

0.8

1.0

Pr

(tra

nsfe

r tim

e <

x)

server 7 tts (cdf)

100050002000050000100000

� Deterministicslow start.

� Bandwidthlimited.

18

Example #2

563 1119 2227 4431 8815x (ms)

0.0

0.2

0.4

0.6

0.8

1.0

Pr

(tra

nsfe

r tim

e <

x)

server 1 tts (cdf)

100050002000050000100000

� Nondeterministicslow start ⇒multimodaldistributions.

� Modes atmultiples of rtt.

19

Example #3

18 29 46 74 119x (ms)

0.0

0.2

0.4

0.6

0.8

1.0

Pr

(tra

nsfe

r tim

e <

x)

server 2 tts (cdf)

100050002000050000100000

� Buffer-limited.

20

Example #4

121 419 1450 5011 17317x (ms)

0.0

0.2

0.4

0.6

0.8

1.0

Pr

(tra

nsfe

r tim

e <

x)

server 9 tts (cdf)

100050002000050000100000

� Congestionlimited.

� Underestimatingvariability?

21

Evil case #1

101 190 355 665 1244x (ms)

0.0

0.2

0.4

0.6

0.8

1.0

Pr

(tra

nsfe

r tim

e <

x)

server 3 tts (cdf)

100050002000050000100000

� Up to 50,000bytes, not bad.

� Anything over60,000, way off!

22

Server performance

� Server imposes 50 ms delay after 40 packets.

� Model includes processing time in round one, but notafterwards.

� Reminder: real world resists modeling.

23

Evil case #2

19 41 91 201 443x (ms)

0.0

0.2

0.4

0.6

0.8

1.0

Pr

(tra

nsfe

r tim

e <

x)

server 6 tts (cdf)

100050002000050000100000

� Actual times aresharplymultimodal.

� Model smoothesthe modes.

24

Multiple paths

0 100 200 300 400time (ms)

0

20

40

60

80

100

siz

e (

10

00

B)

server 6 timing chart� Akamai-style

content delivery⇒ multimodalrtt.

25

Headlines

� Hybrid model captures transition from slow start tosteady state.

• Lots of parameters, but easy to estimate.

� Non-deterministic slow start sighted.

• TCP characteristic or Linux bug?

26

Ongoing work

� Followup paper:“TCP Self-Clocking and Bandwidth Sharing”.

� Network monitoring/predicting tool.

• Collect active and passive measurements.• Maintain database.• Generate vizualizations.• Answer queries.

27

Had enough?

� Followup paper and additional data available from

http://allendowney.com

� Contact me at

downey@allendowney.com

28