[PPT] - ' $ Prelimina ry Empirical Study of BTC T o ols Ma rk PowerPoint Presentation

SLIDE 1 Prelimina ry Empirical Study

f

BTC T

ls

Ma rk Allman, NASA GRC/BBN IPPM W G Meeting August 2000 ' & $ % 1

SLIDE 2 Background Background

W

e have a draft BTC framew

rk

a round which dierent BTC metho dologies can b e built:

TReno

draft (Mathis)

cap

{ no draft y et

The

basic idea

f

a BTC to

l

is to measure the throughput a

w

utilizing standa rd congestion control could

btain

if

wing
ver

the given net w

rk

path.

A

to

l

that do es not rely

n

the underlying TCP is very attractive b ecause quirks in TCP stacks do not impact the results. ' & $ % IPPM August 2000 2

SLIDE 3 But, A Question... But, A Question...

A

question remains as to whether

r

not a to

l

p ro ducing pack ets acco rding to TCP's congestion control algo rithms can p redict TCP p erfo rmance.

Intuitively

{ y es!

Empirically

{ not sure y et ' & $ % IPPM August 2000 3

SLIDE 4 cap Overview cap Overview

Consists
f

sender (cap ) and receiver (cap d ) p ro cesses.

Use

UDP fo r b

th

\data" and \A CK" pack ets

Advantages:
Allo

ws go

d

control

ver

all b ehavio r (sender loss recovery strategy , dela y ed A CK b ehavio r, etc.)

The

\A CKs" a re cumulative, just as in TCP

Data

loss/reo rdering can b e disambiguated from A CK loss

Disadvantages:
Must

have access to the receiver to run cap d ' & $ % IPPM August 2000 4

SLIDE 5 TReno Overview TReno Overview

Consists
f
nly

a sending p ro cess

Can

use UDP

r

ICMP pack ets to induce the receiver into \A CKing" (ala ping

r

traceroute)

Advantages:
Do

es not require access to the receiver host

Disadvantages:
A

CK loss is the same as data loss since

nly

sp ecic data segments a re A CKed (i.e., no cumulative A CK)

No

control

ver

the receiver's b ehavio r

W

e can emulate things lik e dela y ed A CKs, SA CKs, etc.

The

receiver cannot do things lik e tak e bandwidth estimates (although this is not currently a p roblem) ' & $ % IPPM August 2000 5

SLIDE 6 Metho dology Metho dology

Used

a subset

f

the NIMI sites

Used

31 sites (mostly F reeBSD, a couple NetBSD)

Hosts

excluded due to conguration issues, not net w

rk

issues.

One

measurement consists

f

t w

back-to-back

transfers

Each

transfer is 30 seconds

W

e randomly pick TCP , cap

r

TReno fo r each transfer

W

e have XXX measurements

ver

the course

f

roughly 3 da ys ' & $ % IPPM August 2000 6

SLIDE 7 Metho dology (cont.) Metho dology (cont.)

The

TCP used w as the sto ck version used b y the pa rticula r

p

erating system

W

e increased the so ck et buer sizes to roughly 200 KB

I.e.,

w e used windo w scaling and timestamps (also used in cap and TReno)

W

e disrega rded measurements made with smaller so ck et buer sizes. ' & $ % IPPM August 2000 7

SLIDE 8 Results Results

Throughput

distribution

f

TCP transfers:

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 CDF Throughput (bytes/sec)

' & $ % IPPM August 2000 8

SLIDE 9 Results (cont.) Results (cont.)

Dierence

in throughput, tak e 1:

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.2 0.4 0.6 0.8 1 CDF Percentage Difference in Throughput TCP vs. TCP TCP vs. cap TCP vs. TReno

' & $ % IPPM August 2000 9

SLIDE 10 Results (cont.) Results (cont.)

Dierence

in throughput, tak e 2:

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

1
0.5

0.5 1 CDF Percentage Difference in Throughput TCP vs. TCP TCP vs. cap TCP vs. TReno

' & $ % IPPM August 2000 10

SLIDE 11 Results (cont.) Results (cont.)

Why

the dierence?

cap

's initial RTO is dierent from TCP's (3 secs as

pp
sed

to 6 secs)

cap

's RTO ends up b eing a bit longer than TCP's in some cases

Lik

ely indicating a bug in cap 's hea rtb eat timer emulation co de

BSD

TCP bugs ' & $ % IPPM August 2000 11

SLIDE 12 Results (cont.) Results (cont.)

BSD

TCP bug:

800000 750000 700000 650000 600000 550000 20.000 s 15.000 s 10.000 s 5.000 s

sequence offset relative time 133.138.1.148:3226_==>_204.42.254.25:4753 (time sequence graph)

R R R R R R R R R R

. . . . . . . . . . . . . . . . . . . . ' & $ % IPPM August 2000 12

SLIDE 13 Conclusions Conclusions

Not

denite conclusions... just leanings...

BTC

is lik ely p

ssible

with a sender/receiver measurement metho dology .

Whether
r

not w e can mak e a sender-only metho dology w

rk

is an

p

en question. ' & $ % IPPM August 2000 13

SLIDE 14 F uture W

rk

F uture W

rk
Continue

to crunch the data to determine to what degree cap and/o r TReno need to b e xed to b etter emulate TCP b ehavio r

Keeping

in mind that some

f

the dierences might not b e bugs, but rather legal diversit y , as allo w ed b y RF C 2581.

Run

some measurements using dierent TCP stacks to gure

ut

what so rt

f

va riation exists b et w een currently existing implementations.

I.e.,

cap and/o r TReno might b e dierent from BSD TCP , but no mo re so than another implementation

f

TCP . ' & $ % IPPM August 2000 14

SLIDE 15 F uture W

rk

(cont.) F uture W

rk

(cont.)

Give

cap the abilit y to w

rk

as a sender-side

nly

to

l.
Allo

w a mo re direct compa rison b et w een the sender-only app roach and the sender/receiver app roach currently emplo y ed. ' & $ % IPPM August 2000 15

SLIDE 16 IPPM Implications IPPM Implications

What

do w e do with BTC in IPPM?

I

b elieve the framew

rk

is essentially sound at this p

int

and should b e fo rw a rded to the IESG after a light editing pass.

I

think a do cument based a round the BTC framew

rk

and the current cap to

l

is app rop riate in the nea r-term. ' & $ % IPPM August 2000 16