TCP/IP

Performance

over

Wireless

Links

with

Rate

and

Delay

Variation

Wireless

link

losses

result

in

poor

TCP

throughput

since

losses

are

perceived

as

congestion

by

TCP

resulting

in

source

throttling

In

order

to

mitigate

this

effect

wireless

link

designers

have

augmented

their

system

with

extensive

local

retransmission

mechanisms

In

addition

in

order

to

increase

throughput

intelligent

channel

state

based

scheduling

have

also

been

introduced

While

these

mechanisms

have

reduced

the

impact

of

losses

on

TCP

throughput

and

improved

the

channel

utilization

these

gains

have

come

at

the

expense

of

increased

delay

and

rate

variability

In

this

paper

we

comprehensively

evaluate

the

impact

of

variable

rate

and

variable

delay

on

long-lived

TCP

performance

We

propose

a

model

to

explain

and

predict

TCP

's

throughput

over

a

link

with

variable

rate

and/or

delay

We

also

propose

a

network-based

solution

called

Ack

Regulator

that

mitigates

the

effect

of

variable

rate

and/or

delay

without

significantly

increasing

the

round

trip

time

while

improving

TCP

performance

by

up

to

C.

-LSB-

Network

Architecture

and

Design

-RSB-

Wireless

communication

Algorithms

Performance

Design

Third

generation

wide-area

wireless

networks

are

currently

being

deployed

in

the

United

States

in

the

form

of

technology

-LSB-

-RSB-

with

speeds

up

to

Data-only

enhancements

to

have

already

been

standardized

in

the

standard

-LRB-

also

called

High

Data

Rate

or

HDR

-RRB-

Permission

to

make

digital

or

hard

copies

of

all

or

part

of

this

work

for

personal

or

classroom

use

is

granted

without

fee

provided

that

copies

are

not

made

or

distributed

for

profit

or

commercial

advantage

and

that

copies

bear

this

notice

and

the

full

citation

on

the

first

page

To

copy

otherwise

to

republish

to

post

on

servers

or

to

redistribute

to

lists

requires

prior

specific

permission

and/or

a

fee

MOBICOM

September

Atlanta

Georgia

USA

Copyright

ACM

with

speeds

up

to

Mbps

-LSB-

-RSB-

UMTS

-LSB-

-RSB-

is

the

third

generation

wireless

technology

in

Europe

and

Asia

with

deploy-ments

planned

this

year

As

these

networks

provide

pervasive

internet

access

good

performance

of

TCP

over

these

wireless

links

will

be

critical

for

end

user

satisfaction

While

the

performance

of

TCP

has

been

studied

extensively

over

wireless

links

-LSB-

-RSB-

most

attention

has

been

paid

to

the

impact

of

wireless

channel

losses

on

TCP

Losses

are

perceived

as

congestion

by

TCP

resulting

in

source

throttling

and

very

low

net

throughput

In

order

to

mitigate

the

effects

of

losses

wireless

link

designers

have

augmented

their

system

with

extensive

local

retransmission

mechanisms

For

example

link

layer

retransmission

protocols

such

as

RLP

and

RLC

are

used

in

-LSB-

-RSB-

and

UMTS

-LSB-

-RSB-

respectively

These

mechanisms

ensure

packet

loss

probability

of

less

than

on

the

wireless

link

thereby

mitigating

the

adverse

impact

of

loss

on

TCP

While

these

mechanisms

mitigate

losses

they

also

increase

delay

variability

For

example

as

we

shall

see

in

Section

ping

latencies

vary

between

to

over

second

in

a

system

In

addition

in

order

to

increase

throughput

intelligent

channel

state

based

scheduling

have

also

been

introduced

Channel

state

based

scheduling

-LSB-

-RSB-

refers

to

scheduling

techniques

which

take

the

quality

of

wireless

channel

into

account

while

scheduling

data

packets

of

different

users

at

the

base

station

The

intuition

behind

this

approach

is

that

since

the

channel

quality

varies

asynchronously

with

time

due

to

fading

it

is

preferable

to

give

priority

to

a

user

with

better

channel

quality

at

each

scheduling

epoch

While

strict

priority

could

lead

to

starvation

of

users

with

inferior

channel

quality

a

scheduling

algorithm

such

as

proportional

fair

-LSB-

-RSB-

can

provide

long-term

fairness

among

different

users

However

while

channel-state

based

scheduling

improves

overall

throughput

it

also

increases

rate

variability

Thus

while

the

impact

of

losses

on

TCP

throughput

have

been

significantly

reduced

by

local

link

layer

mechanisms

and

higher

raw

throughput

achieved

by

channel-state

based

scheduling

mechanisms

these

gains

have

come

at

the

expense

of

increased

delay

and

rate

variability

This

rate

and

delay

variability

translates

to

bursty

ack

arrivals

-LRB-

also

called

ack

compression

-RRB-

at

the

TCP

source

Since

TCP

uses

ack

clocking

to

probe

for

more

bandwidth

bursty

ack

arrival

leads

to

release

of

a

burst

of

packets

from

the

TCP

source

When

this

burst

arrives

at

a

link

with

variable

rate

or

delay

it

could

result

in

multiple

packet

losses

These

multiple

losses

significantly

degrade

TCPs

throughput

In

this

paper

we

make

three

main

contributions

First

we

comprehensively

evaluate

the

impact

of

variable

rate

and

variable

delay

on

long-lived

TCP

performance

Second

we

propose

a

model

to

explain

and

predict

TCP

's

throughput

over

a

link

with

variable

rate

and/or

delay

Third

we

propose

a

network-based

solution

called

Ack

Regulator

that

mitigates

the

effect

of

variable

rate

and/or

delay

without

significantly

increasing

the

round

trip

time

thereby

improving

TCP

performance

The

remaining

sections

are

organized

as

follows

In

Section

we

discuss

related

work

In

Section

we

present

the

motivation

for

our

work

using

traces

from

a

system

In

Section

we

describe

a

model

for

computing

the

throughput

of

a

long-lived

TCP

flow

over

links

with

variable

rate

and

variable

delay

We

then

present

a

simple

network-based

solution

called

Ack

Regulator

to

mitigate

the

effect

of

variable

rate/delay

in

Section

In

Section

we

present

extensive

simulation

results

that

compare

TCP

performance

with

and

without

Ack

Regulator

highlighting

the

performance

gains

using

the

Ack

Regulator

when

TCP

is

subjected

to

variable

rate

and

delay

Finally

in

Section

we

present

our

conclusions

In

this

section

we

review

prior

work

on

improving

TCP

performance

over

wireless

networks

Related

work

on

the

modeling

of

TCP

performance

is

presented

in

Section

A

lot

of

prior

work

has

focused

on

avoiding

the

case

of

a

TCP

source

misinterpreting

packet

losses

in

the

wireless

link

as

congestion

signals

In

-LSB-

-RSB-

a

snoop

agent

is

introduced

inside

the

network

to

perform

duplicate

ack

suppression

and

local

retransmissions

on

the

wireless

link

to

enhance

TCP

performance

In

-LSB-

-RSB-

the

TCP

connection

is

split

into

two

separate

connections

one

over

the

fixed

network

and

the

second

over

the

wireless

link

The

second

connection

can

recover

from

losses

quickly

resulting

in

better

throughput

Link-layer

enhancements

for

reducing

wireless

link

losses

including

retransmission

and

forward

error

correction

have

been

proposed

in

-LSB-

-RSB-

Link

layer

retransmission

is

now

part

of

both

the

and

UMTS

standards

-LSB-

-RSB-

In

order

to

handle

disconnections

-LRB-

a

case

of

long-lived

loss

-RRB-

M-TCP

has

been

proposed

-LSB-

-RSB-

The

idea

is

to

send

the

last

ack

with

a

zero-sized

receiver

window

so

that

the

sender

can

be

in

persist

mode

during

the

disconnection

Link

failures

are

also

common

in

Ad

Hoc

networks

and

techniques

to

improve

TCP

performance

in

the

presence

of

link

failures

have

been

proposed

in

-LSB-

-RSB-

Note

that

of

these

approaches

address

specifically

the

impact

of

delay

and

rate

variation

on

TCP

which

is

the

focus

of

this

paper

Several

generic

TCP

enhancements

with

special

applica-bility

to

wireless

links

are

detailed

in

-LSB-

-RSB-

These

include

enabling

the

Time

Stamp

option

use

of

large

window

size

and

window

scale

option

disabling

Van

Jacobson

header

compression

and

the

use

of

Selective

Acknowledgments

-LRB-

Sack

-RRB-

Large

window

size

and

window

scaling

are

necessary

because

of

the

large

delay

of

wireless

link

while

Sack

could

help

TCP

recover

from

multiple

losses

without

the

expensive

timeout

recovery

mechanism

Another

issue

with

large

delay

variation

in

wireless

links

is

spurious

timeouts

where

TCP

unnecessarily

retransmits

a

packet

-LRB-

and

lowers

its

congestion

window

to

a

minimum

-RRB-

after

a

timeout

when

the

packet

is

merely

delayed

In

-LSB-

-RSB-

the

authors

refer

to

rate

variability

due

to

periodic

allocation

and

de-allocation

of

high-speed

channels

in

networks

as

Bandwidth

Oscillation

Bandwidth

Oscillation

can

also

lead

to

spurious

timeouts

in

TCP

because

as

the

rate

changes

from

high

to

low

the

rtt

value

increases

and

a

low

Retransmission

Timeout

-LRB-

RTO

-RRB-

value

causes

a

spurious

retransmission

and

unnecessarily

forces

TCP

into

slow

start

In

-LSB-

-RSB-

the

authors

conduct

experiments

of

TCP

over

GSM

circuit

channels

and

show

that

spurious

timeouts

are

extremely

rare

However

wireless

links

can

have

larger

variations

than

GSM

due

to

processing

delays

and

rate

variations

due

to

channel

state

based

scheduling

Given

the

increased

variability

on

packet

channels

the

use

of

TCP

time

stamp

option

for

finer

tracking

of

TCP

round

trip

times

and

possibly

the

use

of

Eifel

retransmission

timer

-LSB-

-RSB-

instead

of

the

conventional

TCP

timer

can

help

avoid

spurious

timeouts

As

mentioned

earlier

the

effect

of

delay

and

rate

variability

is

ack

compression

and

this

results

in

increased

burstiness

at

the

source

Ack

compression

can

also

be

caused

by

bidirectional

flows

over

regular

wired

networks

or

single

flow

over

networks

with

large

asymmetry

This

phenomenon

has

been

studied

and

several

techniques

have

been

proposed

to

tackle

the

burstiness

of

ack

compression

In

order

to

tackle

burstiness

the

authors

in

-LSB-

-RSB-

propose

several

schemes

that

withholds

acks

such

that

there

is

no

packet

loss

at

the

bottleneck

router

resulting

in

full

throughput

However

the

round

trip

time

is

unbounded

and

can

be

very

large

In

-LSB-

-RSB-

the

authors

implement

an

ack

pacing

technique

at

the

bottleneck

router

to

reduce

burstiness

and

ensure

fairness

among

different

flows

In

the

case

of

asymmetric

channels

solutions

proposed

-LSB-

-RSB-

include

ack

congestion

control

and

ack

filtering

-LRB-

dropping

of

acks

-RRB-

reducing

source

burstiness

by

sender

adaptation

and

giving

priority

to

acks

when

scheduling

inside

the

network

However

the

magnitude

of

asymmetry

in

networks

is

not

large

enough

and

can

be

tolerated

by

TCP

without

ack

congestion

control

or

ack

filtering

according

to

-LSB-

-RSB-

Note

that

in

our

case

ack

compression

occurs

because

of

link

variation

and

not

due

to

asymmetry

or

bidirectional

flows

Thus

we

require

a

solution

that

specifically

adapts

to

link

variation

Moreover

the

node

at

the

edge

of

the

wireless

access

network

is

very

likely

to

be

the

bottleneck

router

-LRB-

given

rates

of

to

Mbps

on

the

wireless

link

-RRB-

and

is

the

element

that

is

exposed

to

varying

delays

and

service

rates

Thus

this

node

is

the

ideal

place

to

regulate

the

acks

in

order

to

improve

TCP

performance

This

is

discussed

in

more

detail

in

the

next

section

MD

RNC

RNC

BS

BS

PDSN

SGSN

BS

Base

Station

MD

Mobile

Device

HA

GGSN

HA

Home

Agent

RNC

Radio

Network

Controller

PDSN

Packet

Data

Service

Node

SGSN

Serving

GPRS

Service

Node

GGSN

Gateway

GPRS

Service

Node

-LRB-

RLP/RLC

-RRB-

Link

Layer

Retransmission

INTER

NET

Figure

network

architecture

A

simplified

architecture

of

a

wireless

network

is

shown

Prob

Ping

latency

-LRB-

ms

-RRB-

Figure

CDF

of

Ping

Latencies

in

Figure

The

base

stations

are

connected

to

a

node

called

the

Radio

Network

Controller

-LRB-

RNC

-RRB-

The

RNC

performs

CDMA

specific

functions

such

as

soft

handoffs

encryption

power

control

etc.

It

also

performs

link

layer

retransmission

using

RLP

-LRB-

RLC

-RRB-

in

-LRB-

UMTS

-RRB-

system

In

the

system

the

RNC

is

connected

to

a

PDSN

using

a

GRE

tunnel

-LRB-

one

form

of

IP

in

IP

tunnel

-RRB-

and

the

PDSN

terminates

PPP

with

the

mobile

device

If

Mobile

IP

service

is

enabled

the

PDSN

also

acts

as

a

Foreign

Agent

and

connects

to

a

Home

Agent

In

the

UMTS

system

the

RNC

is

connected

to

a

SGSN

using

a

GTP

tunnel

-LRB-

another

form

of

IP

in

IP

tunnel

-RRB-

the

SGSN

is

connected

to

a

GGSN

again

through

a

GTP

tunnel

Note

that

the

tunneling

between

the

various

nodes

allows

for

these

nodes

to

be

connected

directly

or

through

IP/ATM

networks

In

this

architecture

the

RNC

receives

a

PPP/IP

packet

through

the

GRE/GTP

tunnel

from

the

PDSN/SGSN

The

RNC

fragments

this

packet

into

a

number

of

radio

frames

and

then

performs

transmission

and

local

retransmission

of

these

radio

frames

using

the

RLP

-LRB-

RLC

-RRB-

protocol

The

base

station

-LRB-

BS

-RRB-

receives

the

radio

frames

from

the

RNC

and

then

schedules

the

transmission

of

the

radio

frames

on

the

wireless

link

using

a

scheduling

algorithm

that

takes

the

wireless

channel

state

into

account

The

mobile

device

receives

the

radio

frames

and

if

it

discovers

loss

of

radio

frames

it

requests

local

retransmission

using

the

RLP

-LRB-

RLC

-RRB-

protocol

Note

that

in

order

to

implement

RLP

-LRB-

RLC

-RRB-

the

RNC

needs

to

keep

a

per-user

queue

of

radio

frames

The

RNC

can

typically

scale

up

to

tens

of

base

stations

and

thousands

of

active

users

In

order

to

illustrate

the

variability

seen

in

a

system

we

obtained

some

traces

from

a

system

The

system

consisted

of

an

integrated

BS/RNC

a

server

connected

to

the

RNC

using

a

Mbps

Ethernet

and

a

mobile

device

connected

to

the

BS

using

a

link

with

downlink

in

infinite

burst

mode

and

uplink

The

infinite

burst

mode

implies

that

the

rate

is

fixed

and

so

the

system

only

had

delay

variability

Figure

plots

the

cumulative

distribution

function

-LRB-

cdf

-RRB-

of

ping

latencies

from

a

set

of

pings

from

the

server

to

the

mobile

device

-LRB-

with

no

observed

loss

-RRB-

While

about

of

the

latency

values

are

below

the

latency

values

go

all

the

way

to

over

with

about

of

the

values

higher

than

In

the

second

experiment

a

TCP

source

at

the

server

using

Sack

with

timestamp

option

transferred

a

MB

file

to

the

mobile

device

The

MTU

was

bytes

with

user

data

size

of

bytes

The

buffer

at

the

RNC

was

larger

than

the

TCP

window

size

and

thus

the

transfer

resulted

in

no

TCP

packet

loss

and

a

maximal

throughput

of

about

We

did

not

have

control

over

the

buffer

size

at

the

RNC

in

Prob

Interack

time

Time

-LRB-

s

-RRB-

Rtt

-LRB-

s

-RRB-

Time

-LRB-

s

-RRB-

-LRB-

a

-RRB-

TCP

Ack

Inter-arrival

-LRB-

b

-RRB-

TCP

rtt

value

Figure

Link

Delay

Variability

The

transmission

time

at

the

bottleneck

link

is

If

the

wireless

link

delay

were

constant

the

TCP

acks

arriving

at

the

source

would

be

evenly

spaced

with

a

duration

of

because

of

the

delayed

ack

feature

of

TCP

-LRB-

every

packets

are

acked

rather

than

every

packet

-RRB-

Figure

-LRB-

a

-RRB-

plots

the

cdf

of

TCP

ack

inter-arrival

time

-LRB-

time

between

two

consecutive

acks

-RRB-

at

the

server

As

can

be

seen

there

is

significant

ack

compression

with

over

of

the

acks

arriving

within

of

the

previous

ack

Note

that

the

ack

packet

size

is

bytes

-LRB-

timestamp

-RRB-

and

ack

transmission

time

on

the

uplink

is

an

interack

spacing

of

less

then

is

a

result

of

uplink

delay

variation

Note

that

the

delay

variability

and

the

resulting

ack

compression

did

not

cause

any

throughput

degradation

in

our

system

This

was

due

to

the

fact

that

the

buffering

in

the

system

was

greater

than

the

TCP

window

size

resulting

in

no

buffer

overflow

loss

Figure

-LRB-

b

-RRB-

depicts

the

TCP

round

trip

time

-LRB-

rtt

-RRB-

values

over

time

Since

the

buffer

at

the

RNC

is

able

to

accommodate

the

whole

TCP

window

the

rtt

increases

to

over

representing

a

case

of

over

packets

in

the

buffer

at

the

RNC

-LRB-

s

-RRB-

Given

an

average

ping

latency

of

and

a

transmission

time

of

for

a

byte

packet

the

bandwidth

delay

product

of

the

link

is

approximately

-LRB-

-RRB-

or

about

packets

Thus

the

system

had

a

buffer

of

over

times

the

bandwidth

delay

product

Given

that

we

had

only

one

TCP

flow

in

the

system

a

buffer

of

over

is

not

a

problem

But

if

every

TCP

flow

is

allocated

a

buffer

of

the

buffer

requirements

at

the

RNC

would

be

very

expensive

since

the

RNC

supports

thousands

of

active

users

Even

discounting

the

cost

of

large

buffers

the

inflated

rtt

value

due

to

the

excessive

buffering

has

several

negative

consequences

as

identified

in

-LSB-

-RSB-

First

an

inflated

rtt

implies

a

large

retransmission

timeout

value

-LRB-

rto

-RRB-

In

the

case

of

multiple

packet

losses

-LRB-

either

on

the

wireless

link

or

in

a

router

elsewhere

in

the

network

-RRB-

a

timeout-based

recovery

would

cause

excessive

delay

especially

if

exponential

backoff

gets

invoked

Second

if

the

timestamp

option

is

not

used

the

rtt

sampling

rate

is

reduced

and

this

can

cause

spurious

timeouts

Third

there

is

a

higher

probability

that

the

data

in

the

queue

becomes

obsolete

-LRB-

for

e.g.

due

to

user

aborting

the

transmission

-RRB-

but

the

queue

will

still

have

to

be

drained

resulting

in

wasted

bandwidth

Thus

while

excessive

buffering

at

the

RNC

can

absorb

the

variability

of

the

wireless

links

without

causing

TCP

throughput

degradation

it

has

significant

negative

side

effects

making

it

an

undesirable

solution

our

system

In

this

section

we

model

the

performance

of

a

single

long-lived

TCP

flow

over

a

network

with

a

single

bottleneck

server

that

exhibits

rate

variation

based

on

a

given

general

distribution

and

a

single

wireless

link

attached

to

the

bottleneck

server

that

exhibits

delay

variation

based

on

another

given

distribution

We

use

a

general

distribution

of

rate

and

delay

values

for

the

discussion

in

this

section

since

we

would

like

to

capture

the

inherent

variation

in

rate

and

delay

that

is

a

characteristic

of

the

wireless

data

environment

Given

that

the

wireless

standards

are

constantly

evolving

the

actual

rate

and

delay

distribution

will

vary

from

one

standard

or

implementation

to

another

and

is

outside

the

scope

of

this

paper

Later

in

Section

we

will

evaluate

TCP

performance

over

a

specific

wireless

link

the

-LRB-

HDR

-RRB-

system

using

simulation

We

would

like

to

model

TCP

performance

in

the

case

of

variable

rate

and

delay

for

two

reasons

One

we

would

like

to

understand

the

dynamics

so

that

we

can

design

an

appropriate

mechanism

to

improve

TCP

performance

Two

we

would

like

to

have

a

more

accurate

model

that

specifically

takes

the

burstiness

caused

by

ack

compression

due

to

rate/delay

variability

into

account

TCP

performance

modeling

has

been

extensively

studied

in

the

literature

-LSB-

-RSB-

Most

of

these

models

assume

constant

delay

and

service

rate

at

the

bottleneck

router

and

calculate

TCP

throughput

in

terms

of

packet

loss

probability

and

round

trip

time

In

-LSB-

-RSB-

the

authors

model

TCP

performance

assuming

deterministic

time

between

congestion

events

-LSB-

-RSB-

In

-LSB-

-RSB-

the

authors

improve

the

throughput

prediction

of

-LSB-

-RSB-

assuming

exponential

time

between

congestion

events

-LRB-

loss

indications

as

Poisson

-RRB-

In

our

case

ack

compressions

and

link

variation

causes

bursty

losses

and

the

deterministic

or

Poisson

loss

models

are

not

likely

to

be

as

accurate

In

-LSB-

-RSB-

the

authors

model

an

UMTS

wireless

network

by

extending

the

model

from

-LSB-

-RSB-

and

inflating

the

rtt

value

to

account

for

the

average

additional

delay

incurred

on

the

wireless

link

However

we

believe

this

will

not

result

in

an

accurate

model

because

-RRB-

the

rtt

value

in

-LSB-

-RSB-

is

already

an

end-to-end

measured

value

and

-RRB-

the

loss

process

is

much

more

bursty

than

the

deterministic

loss

assumption

in

-LSB-

-RSB-

In

-LSB-

-RSB-

the

authors

observe

that

mean

values

are

not

sufficient

to

predict

the

throughput

when

routers

have

varying

bandwidth

and

show

that

increasing

variance

for

the

same

mean

service

rate

decreases

TCP

throughput

However

the

approach

is

numerical

and

provides

little

intuition

in

the

case

of

delay

variance

Our

approach

starts

with

the

model

in

-LSB-

-RSB-

which

describes

how

TCP

functions

in

an

ideal

environment

with

constant

round

trip

time

constant

service

rate

and

suffers

loss

only

through

buffer

overflow

A

brief

summary

of

the

result

from

-LSB-

-RSB-

is

presented

here

before

we

proceed

to

our

model

which

can

be

seen

as

an

extension

We

chose

to

extend

the

model

in

-LSB-

-RSB-

since

it

makes

no

assumption

about

the

nature

of

loss

event

process

-LRB-

which

is

highly

bursty

in

our

case

-RRB-

and

explicitly

accounts

for

link

delay

and

service

rate

-LRB-

which

are

variable

in

our

case

-RRB-

For

simplicity

we

will

only

discuss

the

analysis

of

TCP

Reno

TCP

Sack

can

be

analyzed

similarly

We

also

assume

that

the

sender

is

not

limited

by

the

maximum

receiver

window

simple

modifications

can

be

made

to

the

analysis

for

handling

this

case

Figure

-LRB-

a

-RRB-

shows

how

the

TCP

congestion

window

varies

Ideal

TCP

TCP

with

Variable

Delay

-LRB-

a

-RRB-

Constant

delay

-LRB-

b

-RRB-

Variable

delay

Figure

TCP

Congestion

Window

Evolution

over

time

in

a

constant

rate

and

delay

setting

The

initial

phase

where

TCP

tries

to

probe

for

available

bandwidth

is

the

Slow

Start

phase

After

slow

start

TCP

goes

to

Congestion

avoidance

phase

In

the

case

of

long-lived

TCP

flow

one

can

focus

only

on

the

congestion

avoidance

phase

Let

be

the

constant

service

rate

the

constant

propagation

delay

T

the

minimum

round

trip

time

-LRB-

-RRB-

and

B

the

buffer

size

The

congestion

window

follows

a

regular

saw-tooth

pattern

going

from

W

to

W

max

where

W

W

max

and

W

max

B

Due

to

the

regularity

of

each

of

the

saw-tooth

consider

one

such

saw-tooth

Within

a

single

saw-tooth

the

congestion

avoidance

phase

is

divided

into

two

epochs

In

the

first

epoch

say

epoch

A

the

congestion

window

increases

from

W

to

T

in

time

t

A

with

number

of

packets

sent

n

A

In

the

second

epoch

say

epoch

B

the

congestion

window

increases

from

T

to

W

max

in

time

t

B

with

number

of

packets

sent

n

B

TCP

throughput

-LRB-

ignoring

slow

start

-RRB-

is

simply

given

by

-LRB-

n

A

n

B

-RRB-

-LRB-

t

A

t

B

-RRB-

where

t

A

T

-LRB-

T

W

-RRB-

-LRB-

-RRB-

n

A

-LRB-

W

t

A

t

A

-LRB-

-RRB-

-RRB-

T

-LRB-

-RRB-

t

B

-LRB-

W

max

-LRB-

T

-RRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

n

B

t

B

-LRB-

-RRB-

This

model

while

very

accurate

for

constant

and

T

breaks

down

when

the

constant

propagation

and

service

rate

assumptions

are

not

valid

Figure

-LRB-

b

-RRB-

shows

how

the

congestion

window

becomes

much

more

irregular

when

there

is

substantial

variation

in

the

wireless

link

delay

This

is

because

the

delay

variation

and

ack

compression

result

in

multiple

packet

losses

There

are

three

main

differences

in

the

TCP

congestion

window

behavior

under

variable

rate/delay

from

the

traditional

saw-tooth

behavior

First

while

the

traditional

saw-tooth

behavior

always

results

in

one

packet

loss

due

to

buffer

overflow

we

have

possibilities

for

multiple

packet

losses

due

to

link

variation

To

account

for

this

we

augment

our

model

with

parameters

representing

respectively

the

conditional

probability

of

a

single

packet

loss

double

packet

loss

and

three

or

more

packet

losses

Note

that

by

this

definition

Second

while

the

loss

in

the

traditional

saw-tooth

model

always

occurs

when

window

size

reaches

W

max

B

in

our

model

losses

can

occur

at

different

values

of

window

size

since

and

are

now

both

variables

instead

of

constants

We

capture

this

by

a

parameter

W

f

N

i

W

max

i

N

that

is

the

square

root

of

the

second

moment

of

the

W

max

values

of

each

cycle

The

reason

we

do

this

instead

of

obtaining

a

simple

mean

of

W

max

values

is

because

throughput

is

related

to

W

f

quadratically

-LRB-

since

it

is

the

area

under

the

curve

in

the

cwnd

-LRB-

packets

-RRB-

Time

-LRB-

s

-RRB-

cwnd

-LRB-

packets

-RRB-

Time

-LRB-

s

-RRB-

-LRB-

a

-RRB-

Two

packet

loss

-LRB-

b

-RRB-

Three

packet

loss

Figure

Congestion

Window

with

multiple

losses

congestion

window

graph

-RRB-

Third

due

to

the

fact

that

we

have

multiple

packet

losses

in

our

model

we

need

to

consider

timeouts

and

slow

starts

in

our

throughput

calculation

We

represent

the

timeout

duration

by

the

T

parameter

which

represents

the

average

timeout

value

similar

to

the

timeout

parameter

in

-LSB-

-RSB-

We

now

model

the

highly

variable

congestion

window

behavior

of

a

TCP

source

under

rate/delay

variation

We

first

use

W

f

instead

of

W

max

We

approximate

-LRB-

the

propagation

delay

-RRB-

by

the

average

link

delay

in

the

presence

of

delay

variability

We

replace

-LRB-

the

service

rate

-RRB-

by

the

average

service

rate

in

the

presence

of

rate

variability

Thus

T

becomes

T

-LRB-

-RRB-

Now

consider

three

different

congestion

window

patterns

with

probability

single

loss

followed

by

congestion

avoidance

with

probability

double

loss

followed

by

congestion

avoidance

and

with

probability

triple

loss

and

timeout

followed

by

slow

start

and

congestion

avoidance

First

consider

the

single

loss

event

in

the

congestion

avoidance

phase

This

is

the

classic

saw-tooth

pattern

with

two

epochs

as

identified

in

-LSB-

-RSB-

Lets

call

these

and

epochs

In

epoch

window

size

grows

from

W

to

T

in

time

t

with

number

of

packets

transmitted

n

In

epoch

window

size

grows

from

T

to

W

f

in

time

t

with

number

of

packets

transmitted

n

Thus

with

probability

n

n

packets

are

transmitted

in

time

t

t

where

W

-LRB-

int

-RRB-

W

f

-LRB-

-RRB-

t

T

-LRB-

T

W

-RRB-

-LRB-

-RRB-

n

-LRB-

W

t

t

-LRB-

T

-RRB-

-RRB-

T

-LRB-

-RRB-

t

-LRB-

W

f

-LRB-

T

-RRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

n

t

-LRB-

-RRB-

Next

consider

the

two

loss

event

An

example

of

this

event

is

shown

in

Figure

-LRB-

a

-RRB-

The

trace

is

obtained

using

simulation

described

in

Section

In

this

case

after

the

first

fast

retransmit

-LRB-

around

-RRB-

the

source

receives

another

set

of

duplicate

acks

to

trigger

the

second

fast

retransmit

-LRB-

around

-RRB-

This

fixes

the

two

losses

and

the

congestion

window

starts

growing

from

W

The

second

retransmit

is

triggered

by

the

new

set

of

duplicate

acks

in

response

to

the

first

retransmission

Thus

the

duration

between

the

first

and

second

fast

retransmit

is

the

time

re-quired

for

the

first

retransmission

to

reach

the

receiver

-LRB-

with

a

full

buffer

-RRB-

plus

the

time

for

the

duplicate

ack

to

return

We

assume

that

three

or

more

packet

losses

result

in

a

timeout

this

is

almost

always

true

if

the

source

is

TCP

reno

to

the

sender

In

other

words

this

duration

can

be

approximated

by

the

average

link

delay

with

a

full

buffer

T

B

t

R

We

have

three

epochs

now

epoch

t

R

-LRB-

time

-RRB-

with

one

retransmission

and

zero

new

packet

epoch

-LRB-

-RRB-

with

window

size

growing

from

W

to

T

in

time

t

with

number

of

packets

transmitted

n

and

epoch

-LRB-

-RRB-

as

before

Thus

with

probability

n

n

packets

are

transmitted

in

time

t

R

t

t

where

W

-LRB-

int

-RRB-

W

-LRB-

-RRB-

t

R

T

B

-LRB-

-RRB-

t

T

-LRB-

T

W

-RRB-

-LRB-

-RRB-

n

-LRB-

W

t

t

-LRB-

T

-RRB-

-RRB-

T

-LRB-

-RRB-

Finally

consider

the

three

loss

event

An

example

of

this

event

is

shown

in

Figure

-LRB-

b

-RRB-

In

this

case

after

the

first

fast

retransmit

we

receive

another

set

of

duplicate

acks

to

trigger

the

second

fast

retransmit

This

does

not

fixthe

three

losses

and

TCP

times

out

Thus

we

now

have

five

epochs

first

is

the

retransmission

epoch

-LRB-

-RRB-

with

time

t

R

and

zero

new

packet

second

is

the

timeout

epoch

-LRB-

-RRB-

with

time

T

and

zero

new

packet

third

is

the

slow

start

epoch

-LRB-

-RRB-

where

the

window

grows

exponentially

up

to

previous

ssthresh

value

of

W

in

time

t

ss

-LRB-

Eqn

-RRB-

with

number

of

packets

transmitted

n

ss

-LRB-

Eqn

-RRB-

fourth

is

epoch

-LRB-

-RRB-

where

the

window

size

grows

from

W

to

T

in

time

t

-LRB-

Eqn

-RRB-

with

number

of

packets

transmitted

n

-LRB-

Eqn

-RRB-

and

fifth

is

epoch

-LRB-

-RRB-

as

before

Thus

with

probability

n

ss

n

n

packets

are

transmitted

in

time

t

R

T

t

ss

t

t

where

W

-LRB-

int

-RRB-

W

-LRB-

-RRB-

t

ss

T

log

-LRB-

W

-RRB-

-LRB-

-RRB-

n

ss

W

T

-LRB-

-RRB-

t

T

-LRB-

T

W

-RRB-

-LRB-

-RRB-

n

-LRB-

W

t

t

-LRB-

T

-RRB-

-RRB-

T

-LRB-

-RRB-

Given

that

the

different

types

of

packet

loss

events

are

independent

and

using

the

average

TCP

throughput

can

now

be

approximated

by

a

weighted

combination

of

the

three

types

of

loss

events

to

be

-LRB-

n

ss

n

-RRB-

n

n

n

-LRB-

t

R

T

t

ss

t

-RRB-

-LRB-

t

R

t

-RRB-

t

t

-LRB-

-RRB-

If

any

of

t

are

less

than

those

respective

epochs

do

not

occur

and

we

can

use

the

above

equation

while

setting

the

respective

n

t

to

zero

In

this

paper

we

infer

parameters

such

as

W

f

and

T

from

the

traces

Models

such

as

-LSB-

-RSB-

also

infer

the

loss

probability

round

trip

time

and

timeout

durations

from

traces

Table

lists

the

various

parameters

used

by

the

different

models

for

simulations

with

rate

and

delay

variability

We

use

a

packet

size

of

bytes

a

buffer

of

which

represents

the

product

of

the

average

bandwidth

times

average

delay

and

we

ensure

that

the

source

is

not

window

limited

T

D

and

T

O

denote

the

number

of

loss

events

that

are

of

the

triple

duplicate

and

timeout

type

respectively

and

these

values

are

used

by

models

in

-LSB-

-RSB-

and

-LSB-

-RSB-

The

simulation

using

analysis

similar

to

-LSB-

-RSB-

and

assuming

adequate

buffer

so

that

there

is

no

loss

in

slow

start

Item

Rate

-LRB-

Kb/s

-RRB-

Delay

-LRB-

ms

-RRB-

pkts

TD

TO

T

rtt

W

f

T

e

-LRB-

-RRB-

e

-LRB-

-RRB-

e

-LRB-

-RRB-

u

-LRB-

-RRB-

u

-LRB-

-RRB-

u

-LRB-

-RRB-

u

-LRB-

-RRB-

e

-LRB-

-RRB-

u

-LRB-

-RRB-

e

-LRB-

-RRB-

Table

Simulation

and

Model

parameters

Item

Simulator

Goodput

Model

-LSB-

-RSB-

-LRB-

accu

-RRB-

Model

-LSB-

-RSB-

-LRB-

accu

-RRB-

Model

-LSB-

Eqn

-RSB-

-LRB-

accu

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Table

Simulation

and

Model

throughput

values

is

run

for

seconds

We

simulate

delay

and

rate

variability

with

exponential

and

uniform

distributions

respectively

-LRB-

u

-LRB-

a

b

-RRB-

in

the

table

represents

uniform

distribution

with

mean

a

and

standard

deviation

b

while

e

-LRB-

a

-RRB-

represents

an

exponential

distribution

with

mean

a

-RRB-

The

details

of

the

simulation

are

presented

in

Section

Table

compares

the

throughput

of

simulation

of

different

distributions

for

rate

and

delay

variability

at

the

server

and

the

throughput

predicted

by

the

exact

equation

of

the

model

in

-LSB-

-RSB-

the

Poisson

model

in

-LSB-

-RSB-

and

by

equation

The

accuracy

of

the

prediction

defined

as

minus

the

ratio

of

the

difference

between

the

model

and

simulation

throughput

value

over

the

simulation

throughput

value

is

listed

in

the

parenthesis

As

the

last

column

shows

the

match

between

our

model

and

simulation

is

extremely

accurate

when

the

delay/rate

variation

is

small

and

the

match

is

still

well

over

even

when

the

variation

is

large

The

Poisson

loss

model

used

in

-LSB-

-RSB-

performs

very

well

when

the

variability

is

low

but

understandably

does

not

predict

well

when

variability

increases

The

deterministic

loss

model

seems

to

consistently

overestimate

the

throughput

From

Table

one

can

clearly

see

the

impact

of

delay

and

rate

variability

As

the

variability

increases

the

probability

of

double

loss

and

three

or

more

losses

-LRB-

-RRB-

start

increasing

while

the

goodput

of

the

TCP

flow

starts

decreasing

For

example

comparing

case

to

case

decreases

from

to

while

increases

Increases

in

and

come

about

because

when

the

product

T

decreases

a

pipe

that

used

to

accommodate

more

packets

suddenly

becomes

smaller

causing

additional

packet

losses

Given

that

n

t

n

-LRB-

t

R

t

-RRB-

-LRB-

n

ss

n

-RRB-

-LRB-

t

R

T

t

ss

t

-RRB-

any

solution

that

improves

TCP

performance

must

reduce

the

occurrence

of

multiple

packet

losses

and

We

present

a

solution

that

tries

to

achieve

this

in

the

next

section

In

this

section

we

present

our

network-based

solution

for

improving

TCP

performance

in

the

presence

of

varying

bandwidth

and

delay

The

solution

is

designed

for

improving

the

performance

of

TCP

flows

towards

the

mobile

host

-LRB-

for

downloading-type

applications

-RRB-

since

links

like

HDR

are

designed

for

such

applications

The

solution

is

implemented

at

the

wireless

edge

specifically

at

the

RNC

at

the

layer

just

above

RLP/RLC

Note

that

in

order

to

implement

the

standard-based

RLP/RLC

the

RNC

already

needs

to

maintain

a

per-user

queue

Our

solution

requires

a

per-TCP-flow

queue

which

should

not

result

in

significant

additional

overhead

given

the

low

bandwidth

nature

of

the

wireless

environment

We

also

assume

that

the

data

and

ack

packets

go

through

the

same

RNC

this

is

true

in

the

case

of

networks

where

the

TCP

flow

is

anchored

at

the

RNC

because

of

the

presence

of

soft

handoff

and

RLP

We

desire

a

solution

that

is

simple

to

implement

and

remains

robust

across

different

implementations

of

TCP

To

this

end

we

focus

only

on

the

congestion

avoidance

phase

of

TCP

and

aim

to

achieve

the

classic

saw-tooth

congestion

window

behavior

even

in

the

presence

of

varying

rates

and

delays

by

controlling

the

buffer

overflow

process

in

the

bottleneck

link

We

also

assume

for

this

discussion

that

every

packet

is

acknowledged

-LRB-

the

discussion

can

be

easily

modified

to

account

for

delayed

acks

where

single

ack

packets

acknowledge

multiple

data

packets

-RRB-

Our

solution

is

called

the

Ack

Regulator

since

it

regulates

the

flow

of

acks

back

to

the

TCP

source

The

intuition

behind

the

regulation

algorithm

is

to

avoid

any

buffer

overflow

loss

until

the

congestion

window

at

the

TCP

source

reaches

a

pre-determined

threshold

and

beyond

that

allow

only

a

single

buffer

overflow

loss

This

ensures

that

the

TCP

source

operates

mainly

in

the

congestion

avoidance

phase

with

congestion

window

exhibiting

the

classic

saw-tooth

behavior

Before

we

present

our

solution

we

describe

two

variables

that

will

aid

in

the

presentation

of

our

solution

ConservativeMode

Mode

of

operation

during

which

DataSeqNoLast

-LRB-

DL

-RRB-

Largest

Sequence

of

Last

Data

Packet

Received

DataSeqNoFirst

-LRB-

DF

-RRB-

Largest

Sequence

of

Last

Data

Packet

Sent

AckSeqNoLast

-LRB-

AL

-RRB-

Largest

Sequence

of

Last

Ack

Packet

Received

AckSeqNoFirst

-LRB-

AF

-RRB-

Largest

Sequence

of

Last

Ack

Packet

Sent

DL

DF

AF

AL

Per-Flow

Data

and

Ack

Queue

on

RNC

Wireless

Network

Wireline

Network

Data

Queue

Ack

Queue

QueueLength

QueueLim

Figure

Ack

Regulator

Implementation

each

time

an

ack

is

sent

back

towards

the

TCP

source

there

is

buffer

space

for

at

least

two

data

packets

from

the

source

Note

that

if

TCP

operates

in

the

congestion

avoidance

phase

there

would

be

no

buffer

overflow

loss

as

long

as

the

algorithm

operates

in

conservative

mode

This

follows

from

the

fact

that

during

congestion

avoidance

phase

TCP

increases

its

window

size

by

at

most

one

on

reception

of

an

ack

This

implies

that

on

reception

of

an

ack

TCP

source

sends

either

one

packet

-LRB-

no

window

increase

-RRB-

or

two

packets

-LRB-

window

increase

-RRB-

Therefore

if

there

is

space

for

at

least

two

packets

in

the

buffer

at

the

time

of

an

ack

being

sent

back

there

can

be

no

packet

loss

AckReleaseCount

The

sum

of

total

number

of

acks

sent

back

towards

the

source

and

the

total

number

of

data

packets

from

the

source

in

transit

towards

the

RNC

due

to

previous

acks

released

assuming

TCP

source

window

is

constant

AckReleaseCount

represents

the

number

of

packets

that

can

be

expected

to

arrive

in

the

buffer

at

the

RNC

assuming

that

the

source

window

size

remains

constant

Thus

buffer

space

equal

to

AckReleaseCount

must

be

reserved

whenever

a

new

ack

is

sent

back

to

the

source

if

buffer

overflow

is

to

be

avoided

On

Enque

of

Ack/Deque

of

data

packet

AcksSent

BufferAvail

QueueLim-QueueLength

BufferAvail

-LRB-

AckReleaseCount

ConservativeMode

-RRB-

if

-LRB-

BufferAvail

-RRB-

if

-LRB-

AckSeqNoLast-AckSeqNoFirst

BufferAvail

-RRB-

AcksSent

-LRB-

AckSeqNoLast-AckSeqNoFirst

-RRB-

AckSeqNoFirst

AckSeqNoLast

else

AckSeqNoFirst

BufferAvail

AcksSent

BufferAvail

Send

acks

up

to

AckSeqNoFirst

Figure

Ack

Regulator

processing

at

the

RNC

Figure

shows

the

data

and

ack

flow

and

the

queue

variables

involved

in

the

Ack

Regulator

algorithm

which

is

presented

in

Figure

We

assume

for

now

that

the

AckReleaseCount

and

ConservativeMode

variables

are

as

defined

earlier

We

later

discuss

how

these

variables

are

updated

The

Ack

Regulator

algorithm

runs

on

every

transmission

of

a

data

packet

-LRB-

deque

-RRB-

and

every

arrival

of

an

ack

packet

-LRB-

enque

-RRB-

The

instantaneous

buffer

availability

in

the

data

queue

is

maintained

by

the

BufferAvail

variable

-LRB-

line

-RRB-

BufferAvail

is

then

reduced

by

the

AckReleaseCount

and

the

ConservativeMode

variables

-LRB-

line

-RRB-

Depending

on

the

value

of

the

ConservativeMode

variable

-LRB-

or

-RRB-

the

algorithm

operates

in

two

modes

a

conservative

mode

or

a

non-conservative

respectively

In

the

conservative

mode

an

extra

buffer

space

is

reserved

in

the

data

queue

to

ensure

that

there

is

no

loss

even

if

TCP

congestion

window

is

increased

by

while

in

the

non-conservative

mode

a

single

packet

loss

occurs

if

TCP

increases

its

congestion

window

by

Now

after

taking

AckReleaseCount

and

ConservativeMode

variables

into

account

if

there

is

at

least

one

buffer

space

available

-LRB-

line

-RRB-

and

if

the

number

of

acks

present

in

the

ack

queue

-LRB-

AckSeqNoLast

AckSeqNoFirst

-RRB-

is

lesser

than

BufferAvail

all

those

acks

are

sent

to

the

source

-LRB-

lines

-RRB-

otherwise

only

BufferAvail

number

of

acks

are

sent

to

the

source

-LRB-

lines

-RRB-

Note

that

the

actual

transmission

of

acks

-LRB-

line

-RRB-

is

not

presented

here

The

transmission

of

AcksSent

acks

can

be

performed

one

ack

at

a

time

or

acks

can

be

bunched

together

due

to

the

cumulative

nature

of

TCP

acks

However

care

must

be

taken

to

preserve

the

duplicate

acks

since

the

TCP

source

relies

on

the

number

of

duplicate

acks

to

adjust

its

congestion

window

Also

whenever

three

or

more

duplicate

acks

are

sent

back

it

is

important

that

one

extra

buffer

space

be

reserved

to

account

for

the

fast

retransmission

algorithm

Additional

buffer

reservations

of

two

packets

to

account

for

the

Limited

Transmit

algorithm

-LSB-

-RSB-

can

also

be

provided

for

if

necessary

Initialize

ConservativeMode

On

Enque

of

ack

packet

if

-LRB-

-LRB-

DataSeqNoLast-AckSeqNoFirst

-RRB-

QueueLim

-RRB-

ConservativeMode

On

Enque

and

Drop

of

data

packet

Conservative

Mode

On

Enque/Deque

of

data

packet

if

-LRB-

-LRB-

-LRB-

DataSeqNoLast-AckSeqNoFirst

-RRB-

-RRB-

OR

-LRB-

DataQueueLength

-RRB-

-RRB-

ConservativeMode

Figure

ConservativeMode

updates

We

now

present

the

algorithm

-LRB-

Figure

-RRB-

for

updating

the

ConservativeMode

variable

which

controls

the

switching

of

the

Ack

Regulator

algorithm

between

the

conservative

and

the

non-conservative

modes

The

algorithm

starts

in

conservative

mode

-LRB-

line

-RRB-

Whenever

a

targeted

TCP

window

size

is

reached

-LRB-

in

this

case

QueueLim

-RRB-

the

algorithm

is

switched

into

non-conservative

mode

-LRB-

line

-RRB-

TCP

Window

Size

is

approximated

here

by

the

difference

between

the

largest

sequence

number

in

the

data

queue

and

the

sequence

number

in

the

ack

queue

This

is

a

reasonable

approximation

in

our

case

since

the

wireless

link

is

likely

the

bottleneck

and

most

-LRB-

if

not

all

-RRB-

of

the

queuing

is

done

at

the

RNC

When

operating

in

the

non-conservative

mode

no

additional

buffer

space

is

reserved

This

implies

that

there

will

be

single

loss

the

next

time

the

TCP

source

increases

it

window

size

At

the

detection

of

the

packet

loss

the

algorithm

again

switches

back

to

the

conservative

mode

-LRB-

line

-RRB-

This

ensures

that

losses

are

of

the

single

loss

variety

as

long

as

the

estimate

of

AckReleaseCount

is

conservative

Line

in

the

algorithm

results

in

a

switch

back

into

conservative

mode

whenever

the

data

queue

length

goes

to

zero

or

whenever

the

TCP

window

size

is

halved

This

handles

the

case

when

TCP

reacts

to

losses

elsewhere

in

the

network

and

the

Ack

Regulator

can

go

back

to

being

conservative

Note

that

if

the

TCP

source

is

ECN

capable

instead

of

switching

to

non-conservative

mode

the

Ack

Regulator

can

simply

mark

the

ECN

bit

to

signal

the

source

to

reduce

its

congestion

window

resulting

in

no

packet

loss

Initialize

AckReleaseCount

On

Enque

of

Ack/Deque

of

data

packet

-LRB-

after

processing

in

Fig

-RRB-

AckReleaseCount

AcksSent

On

Enque

of

data

packet

if

-LRB-

AckReleaseCount

-RRB-

AckReleaseCount

On

Deque

of

data

packet

if

-LRB-

DataQueueLength

-RRB-

AckReleaseCount

Figure

AckReleaseCount

updates

We

finally

present

the

algorithm

for

updating

the

AckReleaseCount

variable

in

Figure

Since

AckReleaseCount

estimates

the

expected

number

of

data

packets

that

are

arriving

and

reserves

buffer

space

for

them

it

is

important

to

get

an

accurate

estimate

An

overestimate

of

AckReleaseCount

would

result

in

unnecessary

reservation

of

buffers

that

wo

n't

be

occupied

while

an

underestimate

of

AckReleaseCount

can

lead

to

buffer

overflow

loss

-LRB-

es

-RRB-

even

in

conservative

mode

due

to

inadequate

reservation

With

the

knowledge

of

the

exact

version

of

the

TCP

source

and

the

round

trip

time

from

the

RNC

to

the

source

it

is

possible

to

compute

an

exact

estimate

of

AckReleaseCount

However

since

we

would

like

to

be

agnostic

to

TCP

version

as

far

as

possible

and

also

be

robust

against

varying

round

trip

times

on

the

wired

network

our

algorithm

tries

to

maintain

a

conservative

estimate

of

AckReleaseCount

Whenever

we

send

acks

back

to

the

source

we

update

AckReleaseCount

by

that

many

acks

-LRB-

line

-RRB-

Likewise

whenever

a

data

packet

arrives

into

the

RNC

from

the

source

we

decrement

the

variable

while

ensuring

that

it

does

not

go

below

zero

-LRB-

line

-RRB-

While

maintaining

a

non-negative

AckReleaseCount

in

this

manner

avoids

underestimation

it

also

can

result

in

unbounded

growth

of

AckReleaseCount

leading

to

significant

overestimation

as

errors

accumulate

For

example

we

increase

AckReleaseCount

whenever

we

send

acks

back

to

the

source

however

if

TCP

is

reducing

its

window

size

due

to

loss

we

can

not

expect

any

data

packets

in

response

to

the

acks

being

released

Thus

over

time

AckReleaseCount

can

grow

in

an

unbounded

manner

In

order

to

avoid

this

scenario

we

reset

AckReleaseCount

to

zero

-LRB-

line

-RRB-

whenever

the

data

queue

is

empty

Thus

while

this

reset

operation

is

necessary

for

synchronizing

the

real

and

estimated

AckReleaseCount

after

a

loss

it

is

not

a

conservative

mechanism

in

general

since

a

AckReleaseCount

of

zero

implies

that

no

buffer

space

is

currently

reserved

for

any

incoming

data

packets

that

are

unaccounted

for

However

by

doing

the

reset

only

when

the

data

queue

is

empty

we

significantly

reduce

the

chance

of

the

unaccounted

data

packets

causing

a

buffer

overflow

loss

We

discuss

the

impact

of

this

estimation

algorithm

of

AckReleaseCount

in

Section

Finally

we

assume

that

there

is

enough

buffer

space

for

RNC

Sn

Mn

V

L

Mb/s

D

ms

L

Mb/s

D

ms

FR

Mb/s

FD

ms

RR

Mb/s

RD

ms

Figure

Simulation

Topology

the

ack

packets

in

the

RNC

The

maximum

number

of

ack

packets

is

the

maximum

window

size

achieved

by

the

TCP

flow

-LRB-

QueueLim

in

our

algorithm

-RRB-

Ack

packets

do

not

have

to

be

buffered

as

is

since

storing

the

sequence

numbers

is

sufficient

-LRB-

however

care

should

be

taken

to

preserve

duplicate

ack

sequence

numbers

as

is

-RRB-

Thus

memory

requirement

for

ack

storage

is

very

minimal

In

this

section

we

present

detailed

simulation

results

comparing

the

performance

of

TCP

Reno

and

TCP

Sack

in

the

presence

and

absence

of

the

Ack

Regulator

First

we

study

the

effect

of

variable

bandwidth

and

variable

delay

using

different

distributions

on

the

throughput

of

a

single

long-lived

TCP

flow

Next

we

present

a

model

for

-LRB-

HDR

-RRB-

system

-LRB-

which

exhibits

both

variable

rate

and

variable

delay

-RRB-

and

evaluate

the

performance

of

a

single

TCP

flow

in

the

HDR

environment

Then

we

present

the

performance

of

multiple

TCP

flows

sharing

a

single

HDR

wireless

link

Finally

we

briefly

discuss

the

impact

of

different

parameters

affecting

the

behavior

of

Ack

Regulator

All

simulations

are

performed

using

The

simulation

topology

used

is

shown

in

Figure

S

i

i

n

corresponds

to

the

set

of

TCP

source

nodes

sending

packets

to

a

set

of

the

TCP

sink

nodes

M

i

i

n.

Each

set

of

S

i

M

i

nodes

form

a

TCP

pair

The

RNC

is

connected

to

the

M

i

nodes

through

a

V

-LRB-

virtual

-RRB-

node

for

simulation

purposes

L

the

bandwidth

between

S

i

and

the

RNC

is

set

to

and

D

is

set

to

except

in

cases

where

D

is

explicitly

varied

The

forward

wireless

channel

is

simulated

as

having

rate

F

R

and

delay

F

D

and

the

reverse

wireless

channel

has

rate

RR

and

delay

RD.

Each

simulation

run

lasts

for

-LRB-

hr

-RRB-

unless

otherwise

specified

and

all

simulations

use

packet

size

of

TCP

maximum

window

size

is

set

to

Using

such

a

large

window

size

ensures

that

TCP

is

never

window

limited

in

all

experiments

except

in

cases

where

the

window

size

is

explicitly

varied

Variable

Delay

In

this

section

the

effect

of

delay

variation

is

illustrated

by

varying

F

D

the

forward

link

delay

Without

modification

the

use

of

a

random

link

delay

in

the

simulation

will

result

in

out-of-order

packets

since

packet

transmitted

later

with

lower

delay

can

overtake

packets

transmitted

earlier

with

higher

delay

However

since

delay

variability

in

our

model

is

caused

by

factors

that

will

not

result

in

packet

reordering

-LRB-

e.g.

processing

time

variation

-RRB-

and

RLP

delivers

packet

in

sequence

the

simulation

code

is

modified

such

that

packets

can

not

reach

the

next

hop

until

the

packet

transmitted

earlier

has

arrived

This

modification

applies

to

all

simulations

with

variable

link

delay

Figure

-LRB-

a

-RRB-

shows

throughput

for

a

single

TCP

flow

-LRB-

n

-RRB-

for

F

R

and

RR

F

D

has

an

TCP

Throughput

-LRB-

kb/s

-RRB-

Delay

Variance

Reno

Reno

w/AR

Sack

Sack

w/AR

Throughput

-LRB-

kb/s

-RRB-

Buffer

Size

-LRB-

packet

-RRB-

Reno

Reno

w/AR

Sack

Sack

w/AR

BDP

-LRB-

a

-RRB-

Delay

Variability

-LRB-

b

-RRB-

Different

Buffer

Size

Figure

Throughput

with

Variable

Delay

e

-LRB-

x

-RRB-

ponential

distribution

with

a

mean

that

varies

from

to

and

RD

mean

-LRB-

F

D

-RRB-

so

that

average

F

D+RD

is

maintained

at

The

buffer

size

on

the

bottleneck

link

for

each

run

is

set

to

the

product

of

the

mean

throughput

of

-LRB-

or

-RRB-

and

mean

link

delay

-LRB-

s

-RRB-

This

product

will

be

referred

to

as

the

bandwidth-delay

product

-LRB-

BDP

-RRB-

in

later

sections

Additional

delay

distributions

like

uniform

normal

lognormal

and

Poisson

were

also

experimented

with

Since

the

results

are

similar

only

plots

for

an

exponential

delay

distribution

are

shown

As

expected

when

the

delay

variation

increases

throughput

decreases

for

both

TCP

Reno

and

TCP

Sack

By

increasing

the

delay

variance

from

to

throughput

of

TCP

Reno

decreases

by

and

TCP

Sack

decreases

by

On

the

other

hand

TCP

Reno

and

TCP

Sack

flows

which

are

Ack

Regulated

are

much

more

robust

and

its

throughput

decreases

by

only

Relatively

to

one

another

Ack

Regulator

performs

up

to

better

than

TCP

Reno

and

better

than

TCP

Sack

Another

interesting

result

is

that

Ack

Regulator

delivers

the

same

throughput

irrespective

of

whether

the

TCP

source

is

Reno

or

Sack

This

is

understandable

given

the

fact

that

the

Ack

Regulator

tries

to

ensure

that

only

single

buffer

overflow

loss

occurs

and

in

this

regime

Reno

and

Sack

are

known

to

behave

similarly

This

property

of

Ack

Regulator

is

extremely

useful

since

for

a

flow

to

use

TCP

Sack

both

the

sender

and

receiver

needs

to

be

upgraded

Given

that

there

are

still

significant

number

of

web

servers

that

have

not

yet

been

upgraded

to

TCP

Sack

-LSB-

-RSB-

deployment

of

Ack

Regulator

would

ensure

excellent

performance

irrespective

of

the

TCP

version

running

Figure

-LRB-

b

-RRB-

shows

how

throughput

varies

with

buffer

size

with

the

same

set

of

parameters

except

for

F

D

which

is

now

fixed

with

a

mean

of

-LRB-

exponentially

distributed

-RRB-

Even

with

a

very

small

buffer

of

packets

-LRB-

BDP

-RRB-

Ack

Regulator

is

able

to

maintain

a

throughput

of

over

of

the

maximum

throughput

of

Thus

Ack

Regulator

delivers

robust

throughput

performance

across

different

buffer

sizes

This

property

is

very

important

in

a

varying

rate

and

delay

environment

of

a

wireless

system

since

it

is

difficult

to

size

the

system

with

an

optimal

buffer

size

given

that

the

BDP

also

varies

with

time

For

a

buffer

of

packets

the

improvement

over

TCP

Reno

and

Sack

is

about

and

respectively

As

buffer

size

increases

the

throughput

difference

decreases

With

buffer

size

close

to

packets

-LRB-

BDP

-RRB-

TCP

Sack

performs

close

to

Ack

Regulated

flows

while

improvement

over

TCP

Reno

is

about

Finally

in

Table

we

list

parameter

values

from

the

simulation

for

delay

variance

of

First

consider

Reno

and

Item

Rate

TD

TO

W

f

Kb/s

Reno

Reno

AR

Sack

Sack

AR

Table

Parameters

from

simulation

for

variance

Throughput

-LRB-

kb/s

-RRB-

Rate

Variance

Reno

Reno

w/AR

Sack

Sack

w/AR

Throughput

-LRB-

kb/s

-RRB-

Buffer

Size

-LRB-

packet

-RRB-

Reno

No

AR

Reno

w/AR

Sack

No

AR

Sack

w

AR

BDP

-LRB-

a

-RRB-

Bandwidth

Variability

-LRB-

b

-RRB-

Different

Buffer

Size

Figure

Throughput

with

Variable

Bandwidth

u

-LRB-

x

-RRB-

Reno

with

Ack

Regulator

-LRB-

first

two

rows

-RRB-

It

is

clear

that

Ack

Regulator

is

able

to

significantly

reduce

the

conditional

probability

of

multiple

losses

and

as

well

as

absolute

number

of

loss

events

-LRB-

T

D

and

T

O

-RRB-

resulting

in

substantial

gains

over

Reno

Next

consider

Sack

and

Sack

with

Ack

Regulator

-LRB-

last

two

rows

-RRB-

In

this

case

we

can

see

that

Sack

is

very

effective

in

eliminating

most

of

the

timeout

occurrences

However

Ack

Regulator

is

still

able

to

reduce

the

absolute

number

of

loss

events

by

allowing

the

congestion

window

to

grow

to

higher

values

-LRB-

vs

-RRB-

resulting

in

throughput

gains

Variable

Bandwidth

In

this

section

we

vary

the

link

bandwidth

F

R.

Figure

-LRB-

a

-RRB-

shows

throughput

for

a

single

TCP

flow

F

R

is

uniformly

distributed

with

a

mean

of

Kb/s

and

the

variance

is

varied

from

to

F

D

RR

and

RD

The

buffer

size

on

the

bottleneck

link

for

each

run

is

Again

we

have

experimented

with

other

bandwidth

distributions

but

due

to

lack

of

space

only

uniform

distribution

is

shown

Note

that

with

variable

rate

the

maximum

throughput

achievable

is

different

from

the

mean

rate

For

uniform

distribution

a

simple

closed

form

formula

for

the

throughput

is

simply

b

a

-LRB-

ln

b-ln

a

-RRB-

where

b

is

the

maximum

rate

and

a

is

the

minimum

rate

When

the

rate

variance

increases

throughput

of

TCP

Reno

decreases

as

expected

Compared

to

TCP

Reno

Ack

Regulator

improves

the

throughput

by

up

to

However

TCP

Sack

performs

very

well

and

has

almost

the

same

throughput

as

Ack

Regulated

flows

Based

on

the

calculations

for

maximum

throughput

discussed

before

it

can

be

shown

that

all

flows

except

Reno

achieve

maximum

throughput

This

shows

that

if

rate

variation

is

not

large

enough

TCP

Sack

is

able

to

handle

the

variability

However

for

very

large

rate

variations

-LRB-

e.g.

rate

with

lognormal

distribution

and

a

large

variance

-RRB-

the

performance

of

TCP

Sack

is

worse

than

when

Ack

Regulator

is

present

Figure

-LRB-

b

-RRB-

shows

how

the

throughput

varies

with

buffer

size

Note

that

with

a

lower

throughput

bandwidth

delay

product

is

smaller

than

packets

Again

Ack

Regulated

Throughput

-LRB-

kb/s

-RRB-

Buffer

Size

-LRB-

packet

-RRB-

Reno

No

AR

Reno

w/AR

Sack

No

AR

Sack

w

AR

BDP

RTT

-LRB-

sec

-RRB-

Buffer

Size

-LRB-

packet

-RRB-

Reno

No

AR

Reno

w/AR

Sack

No

AR

Sack

w

AR

BDP

-LRB-

a

-RRB-

Throughput

vs

Buffer

Size

-LRB-

b

-RRB-

rtt

vs

Buffer

Size

Figure

Throughput

and

rtt

for

u

-LRB-

-RRB-

e

-LRB-

-RRB-

TCP

flows

perform

particularly

well

when

the

buffer

size

is

small

With

buffer

size

of

the

improvement

over

TCP

Sack

is

Variable

Delay

and

Bandwidth

In

this

section

we

vary

both

the

bandwidth

and

delay

of

the

wireless

link

F

R

is

uniformly

distributed

with

a

mean

of

Kb/s

and

variance

of

DR

is

exponentially

distributed

with

a

mean

of

RR

and

RD

The

maximum

achievable

throughput

is

Kb/s

The

BDP

is

therefore

about

packets

Figure

-LRB-

a

-RRB-

shows

the

throughput

for

a

single

TCP

flow

with

the

buffer

size

ranging

from

to

The

combination

of

variable

rate

and

delay

has

a

large

negative

impact

on

the

performance

of

TCP

Reno

and

it

is

only

able

to

achieve

to

of

the

bandwidth

of

Ack

Regulated

flows

when

the

buffer

size

is

packets

Even

with

a

buffer

size

of

packets

the

throughput

difference

is

more

than

Throughput

of

TCP

Sack

is

about

to

lower

than

Ack

Regulator

until

the

buffer

size

reaches

packets

-LRB-

about

BDP

-RRB-

One

of

the

cost

of

using

the

Ack

Regulator

is

the

increase

in

average

round

trip

time

-LRB-

rtt

-RRB-

The

average

rtt

values

for

all

types

of

flows

are

shown

in

-LRB-

b

-RRB-

for

different

buffer

sizes

TCP

Reno

has

the

lowest

rtt

followed

by

TCP

Sack

and

the

rate

of

rtt

increase

with

buffer

size

is

comparable

With

Ack

Regulator

rtt

increase

is

comparable

with

unreg-ulated

flows

for

buffer

size

less

than

-LRB-

BDP

-RRB-

For

larger

buffer

sizes

since

Ack

Regulator

uses

times

buffer

size

to

regulate

the

acks

in

conservative

mode

rtt

increases

faster

with

buffer

size

than

regular

TCP

where

only

the

data

packet

buffer

size

contributes

to

rtt

For

example

with

buffer

size

of

Ack

Regulated

flows

have

a

rtt

larger

and

with

buffer

size

of

the

rtt

is

larger

compared

to

TCP

Sack

This

effect

can

be

controlled

by

varying

the

parameter

of

the

Ack

Regulator

Simulation

with

High

Data

Rate

High

Data

Rate

-LRB-

HDR

-RRB-

-LSB-

-RSB-

is

a

Qualcomm

proposed

CDMA

air

interface

standard

-LRB-

-RRB-

for

supporting

high

speed

asymmetrical

data

services

One

of

the

main

ideas

behind

HDR

is

the

use

of

channel-state

based

scheduling

which

transmits

packets

to

the

user

with

the

best

signal-to-noise

ratio

The

actual

rate

available

to

the

selected

user

depends

on

the

current

signal-to-noise

ratio

experienced

by

the

user

The

higher

the

ratio

the

higher

the

rate

available

to

the

user

In

addition

in

order

to

provide

some

form

of

fairness

a

Proportional

Fair

scheduler

is

used

which

provides

long-term

fairness

to

flows

from

different

users

We

use

Qualcomm

's

Proportional

Fair

scheduler

in

our

simulation

with

an

averaging

window

of

time

slots

where

each

Rate

-LRB-

Kb/s

-RRB-

Prob

Rate

-LRB-

Kb/s

-RRB-

Prob

Table

HDR

Data

Rates

for

a

one

user

system

Throughput

-LRB-

Kb/s

-RRB-

Buffer

Size

-LRB-

packet

-RRB-

Reno

No

AR

Reno

w/AR

Sack

No

AR

Sack

w

AR

BDP

Average

RTT

-LRB-

ms

-RRB-

Buffer

Size

-LRB-

Packet

-RRB-

Reno

Reno

w/AR

Sack

Sack

w/AR

BDP

-LRB-

a

-RRB-

Throughput

-LRB-

b

-RRB-

rtt

Figure

Throughput/rtt

with

HDR

Single

Flow

slot

is

ms.

While

the

HDR

system

results

in

higher

raw

throughput

the

rate

and

delay

variation

seen

is

substantial

In

this

section

we

model

a

simplified

HDR

environment

in

focusing

on

the

layer

scheduling

and

packet

fragmentation

The

fading

model

for

the

wireless

link

used

is

based

on

Jake

's

Rayleigh

fading

channel

model

-LSB-

-RSB-

This

gives

us

the

instantaneous

signal-to-noise

ratio

Using

Table

in

-LSB-

-RSB-

which

lists

the

rate

achievable

for

a

given

signal-to-noise

ratio

assuming

a

frame

error

rate

of

less

than

the

achievable

bandwidth

distribution

-LRB-

with

one

user

-RRB-

for

our

simulation

is

shown

in

Table

The

simulation

settings

are

as

follows

F

R

is

a

variable

that

has

a

bandwidth

distribution

of

Table

due

to

the

variations

of

the

fading

conditions

of

the

channel

Based

on

the

guidelines

from

-LSB-

-RSB-

F

D

is

modeled

as

having

a

uniform

distribution

with

mean

and

variance

and

RD

is

modeled

as

having

a

uniform

distribution

with

mean

and

variance

These

are

conservative

estimates

We

expect

delay

variations

in

actual

systems

to

be

higher

-LRB-

for

example

note

the

ping

latencies

from

our

experiment

in

Section

-RRB-

The

uplink

in

a

HDR

system

is

circuit-based

and

RR

is

set

to

be

Figure

-LRB-

a

-RRB-

shows

how

throughput

for

a

single

TCP

flow

varies

with

buffer

size

Assuming

an

average

bandwidth

of

and

a

link

delay

of

BDP

is

packets

Again

the

performance

of

TCP

Reno

flows

that

are

Ack

Regulated

is

significantly

better

than

plain

TCP

Reno

over

the

range

of

buffer

size

experimented

with

improvements

from

to

TCP

Sack

flows

also

performs

worse

than

Ack

Regulated

flows

up

to

buffer

size

of

The

improvement

of

Ack

Regulator

over

TCP

Sack

ranges

from

to

As

mentioned

earlier

one

of

the

costs

of

using

the

Ack

Regulator

is

increase

in

average

rtt

The

average

rtt

for

all

types

of

flows

are

shown

in

-LRB-

b

-RRB-

with

buffer

size

varying

from

to

The

effect

is

similar

to

the

rtt

variation

with

buffer

size

seen

in

Section

Multiple

TCP

Flows

In

this

simulation

the

number

of

flows

-LRB-

n

-RRB-

sharing

the

bottleneck

link

is

increased

to

and

Per-flow

buffering

is

Total

Throughput

-LRB-

Kb/s

-RRB-

Per

Flow

Buffer

Size

-LRB-

Packet

-RRB-

Reno

Flows

Reno

Flows

w/AR

Sack

Flows

Sack

Flows

w/AR

BDP

Total

Throughput

-LRB-

kb/s

-RRB-

Per

Flow

Buffer

Size

-LRB-

Packet

-RRB-

Reno

Flows

Reno

Flows

w/AR

Sack

Flows

Sack

Flows

w/AR

BDP

-LRB-

a

-RRB-

TCP

Flows

-LRB-

b

-RRB-

TCP

Flows

Figure

Throughput

with

HDR

Multiple

Flows

provided

for

each

TCP

flow

For

flows

using

mean

rate

of

packet

and

rtt

of

s

BDP

is

packets

per

flow

For

flows

using

mean

rate

of

packet

and

rtt

of

s

BDP

is

packets

per

flow

As

the

number

of

TCP

flows

increases

the

expected

rate

and

delay

variation

seen

by

individual

flows

also

increases

Thus

even

though

the

total

throughout

of

the

system

increases

with

more

users

due

to

channel-state

based

scheduling

the

improvement

is

reduced

by

the

channel

variability

Figure

-LRB-

a

-RRB-

shows

the

throughput

for

TCP

flows

The

improvement

of

Ack

Regulator

over

TCP

Sack

increases

compared

to

the

single

TCP

case

For

example

the

gain

is

with

per-flow

buffer

size

of

-LRB-

BDP

-RRB-

For

Reno

the

gain

is

even

greater

With

per-flow

buffer

size

of

the

improvement

is

Similar

result

can

also

be

observed

for

the

case

of

TCP

flows

as

shown

in

Figure

-LRB-

b

-RRB-

For

both

TCP

Reno

and

Sack

the

gain

is

about

and

respectively

for

per-flow

buffer

size

of

From

the

figure

it

can

seen

that

for

TCP

Sack

and

Reno

to

achieve

close

to

maximum

throughput

without

Ack

Regulator

at

least

three

times

the

buffer

requirements

of

Ack

Regulator

is

necessary

-LRB-

buffer

requirements

for

acks

in

the

Ack

Regulator

is

negligible

compared

to

the

packet

buffer

since

only

the

sequence

number

needs

to

be

stored

for

the

acks

-RRB-

This

not

only

increases

the

cost

of

the

RNC

which

needs

to

support

thousands

of

active

flows

it

also

has

the

undesirable

side-effects

of

large

rtt

's

that

was

noted

in

Section

With

multiple

TCP

flows

the

issue

of

throughput

fairness

naturally

arises

One

way

to

quantify

how

bandwidth

is

shared

among

flows

is

to

use

the

fairness

indexdescribed

in

-LSB-

-RSB-

This

indexis

computed

as

the

ratio

of

the

square

of

the

total

throughput

to

n

times

the

square

of

the

individual

flow

throughput

If

all

flows

get

the

same

allocation

then

the

fairness

indexis

As

the

differences

in

allocation

increases

fairness

decreases

A

scheme

which

allocates

bandwidth

to

only

a

few

selected

users

has

a

fairness

indexnear

Computation

of

this

indexis

performed

for

all

multiple

flows

simulation

and

the

indexis

greater

than

in

all

cases

This

result

is

expected

since

with

per

flow

buffering

and

proportional

fair

scheduling

the

long

term

throughput

of

many

TCP

long-lived

flows

sharing

the

same

link

should

be

fair

Parameters

affecting

the

performance

of

Ack

Regulator

Due

to

lack

of

space

we

will

only

briefly

present

the

results

of

varying

parameters

such

as

wired

network

latency

and

As

the

network

latency

is

varied

from

to

throughput

decreases

by

and

for

Reno

and

Reno

with

Ack

Regulator

flows

respectively

Most

of

the

decrease

can

be

accounted

for

by

the

impact

of

increase

in

latency

on

TCP

throughput

The

result

shows

that

the

AckReleaseCount

estimation

algorithm

is

effective

and

hence

the

Ack

Regulator

is

able

to

reserve

the

appropriate

amount

of

buffer

for

expected

packet

arrivals

even

with

substantial

wireline

delay

In

another

experiment

the

parameter

in

an

Ack

Regulated

TCP

flow

is

varied

from

to

When

is

increased

from

to

the

TCP

flow

is

able

to

achieve

its

maximum

throughput

at

a

smaller

buffer

size

As

increases

the

rtt

also

increases

and

when

is

increased

to

throughput

decreases

for

larger

buffer

sizes

-LRB-

-RRB-

The

decrease

in

throughput

is

caused

by

the

accumulation

of

sufficiently

large

amount

of

duplicate

acks

that

are

sent

to

the

TCP

sender

A

value

of

appears

to

be

a

good

choice

balancing

throughput

and

rtt

for

reasonable

buffer

sizes

Summary

of

Results

and

Discussion

In

this

section

we

first

summarize

the

results

from

the

simulation

experiments

and

then

briefly

touch

upon

other

issues

We

first

started

with

experiments

using

a

wireless

link

with

variable

delay

We

showed

that

Ack

Regulator

delivers

performance

up

to

better

than

TCP

Reno

and

better

than

TCP

Sack

when

the

buffer

size

was

set

to

one

BDP

We

then

examined

the

impact

of

a

wireless

link

with

variable

rate

We

saw

that

when

the

rate

variance

increases

throughput

of

TCP

Reno

decreases

as

expected

Compared

to

TCP

Reno

Ack

Regulator

improves

the

throughput

by

up

to

However

TCP

Sack

performs

very

well

and

has

almost

the

same

throughput

as

Ack

Regulated

flows

as

long

as

the

rate

variation

is

not

extremely

large

We

next

considered

the

impact

of

a

wireless

link

with

variable

delay

and

variable

rate

We

found

that

this

combination

had

a

large

negative

impact

on

the

performance

of

both

TCP

Reno

and

Sack

-LRB-

up

to

and

improvement

respectively

for

Ack

Regulated

flows

-RRB-

We

then

considered

a

specific

wireless

link

standard

called

HDR

which

exhibits

both

variable

delay

and

variable

rate

The

results

were

as

expected

with

Ack

Regulator

improving

TCP

Reno

performance

by

to

and

TCP

Sack

by

to

We

then

evaluated

the

impact

of

multiple

TCP

flows

sharing

the

HDR

link

The

gains

of

Ack

Regulator

over

normal

TCP

flows

were

even

greater

in

this

case

-LRB-

with

to

improvements

-RRB-

when

the

buffer

size

is

set

to

one

BDP

In

general

we

showed

that

Ack

Regulator

delivers

the

same

high

throughput

irrespective

of

whether

the

TCP

flow

is

Reno

or

Sack

We

further

showed

that

Ack

Regulator

delivers

robust

throughput

performance

across

different

buffer

sizes

with

the

performance

improvement

of

Ack

Regulator

increasing

as

buffer

size

is

reduced

We

only

considered

TCP

flows

towards

the

mobile

host

-LRB-

for

downloading-type

applications

-RRB-

since

links

like

HDR

are

designed

for

such

applications

In

the

case

of

TCP

flows

in

the

other

direction

-LRB-

from

the

mobile

host

-RRB-

Ack

Regulator

can

be

implemented

if

necessary

at

the

mobile

host

to

optimize

the

use

of

buffer

on

the

wireless

interface

card

Finally

Ack

Regulator

can

not

be

used

if

the

flow

uses

end-to-end

IPSEC

This

is

also

true

for

all

performance

enhancing

proxies

However

we

believe

that

proxies

for

performance

improvement

are

critical

in

current

wireless

networks

In

order

to

allow

for

these

proxies

without

compromising

security

a

split

security

model

can

be

adopted

where

the

RNC

under

the

control

of

the

network

provider

becomes

a

trusted

element

In

this

model

a

VPN

approach

to

security

-LRB-

say

using

IPSEC

-RRB-

is

used

on

the

wireline

network

between

the

RNC

and

the

correspondent

host

and

authentication

and

link-layer

encryption

mechanisms

are

used

between

the

RNC

and

mobile

host

This

allows

the

RNC

to

support

proxies

such

as

the

Ack

Regulator

to

improve

performance

without

compromising

security

In

this

paper

we

comprehensively

evaluated

the

impact

of

variable

rate

and

variable

delay

on

TCP

performance

We

first

proposed

a

model

to

explain

and

predict

TCP

's

throughput

over

a

link

with

variable

rate

and

delay

Our

model

was

able

to

accurately

-LRB-

better

than

-RRB-

predict

throughput

of

TCP

flows

even

in

the

case

of

large

delay

and

rate

variation

Based

on

our

TCP

model

we

proposed

a

network

based

solution

called

Ack

Regulator

to

mitigate

the

effect

of

rate

and

delay

variability

The

performance

of

Ack

Regulator

was

evaluated

extensively

using

both

general

models

for

rate

and

delay

variability

as

well

as

a

simplified

model

of

a

rd

Generation

high

speed

wireless

data

air

interface

Ack

Regulator

was

able

to

improve

the

performance

of

TCP

Reno

and

TCP

Sack

by

up

to

without

significantly

increasingly

the

round

trip

time

We

also

showed

that

Ack

Regulator

delivers

the

same

high

throughput

irrespective

of

whether

the

TCP

source

is

Reno

or

Sack

Furthermore

Ack

Regulator

also

delivered

robust

throughput

performance

across

different

buffer

sizes

Given

the

difficulties

in

knowing

in

advance

the

achievable

throughput

and

delay

-LRB-

and

hence

the

correct

BDP

value

-RRB-

a

scheme

like

Ack

Regulator

which

works

well

for

both

large

and

small

buffers

is

essential

In

summary

Ack

Regulator

is

an

effective

network-based

solution

that

significantly

improves

TCP

performance

over

wireless

links

with

variable

rate

and

delay

The

authors

would

like

to

thank

Lijun

Qian

for

providing

the

fading

code

used

in

the

HDR

simulation

Clement

Lee

and

Girish

Chandranmenon

for

providing

the

and

Sandy

Thuel

for

comments

on

earlier

versions

of

this

paper

-LSB-

-RSB-

E.

Altman

K.

Avrachenkov

and

C.

Barakat

A

Stochastic

Model

of

TCP/IP

with

Stationary

Random

Loss

in

Proceedings

of

SIGCOMM

-LSB-

-RSB-

F.

Baccelli

and

D.

Hong

TCP

is

Max-Plus

Linear

in

Proceedings

of

SIGCOMM

-LSB-

-RSB-

A.

Bakre

and

B.R.

Badrinath

Handoff

and

System

Support

for

Indirect

TCP/IP

in

proceedings

of

Second

UsenixSymposium

on

Mobile

and

Location-Independent

Computing

Apr

-LSB-

-RSB-

H.

Balakrishnan

et

al.

Improving

TCP/IP

Performance

over

Wireless

Networks

in

proceedings

of

ACM

Mobicom

Nov

-LSB-

-RSB-

H.

Balakrishnan

V.N.

Padmanabhan

R.H.

Katz

The

Effects

of

Asymmetry

on

TCP

Performance

Proc

ACM/IEEE

Mobicom

Sep.

-LSB-

-RSB-

P.

Bender

et

al.

A

Bandwidth

Efficient

High

Speed

Wireless

Data

Service

for

Nomadic

Users

in

IEEE

Communications

Magazine

Jul

-LSB-

-RSB-

P.

Bhagwat

at

al

Enhancing

Throughput

over

Wireless

LANs

Using

Channel

State

Dependent

Packet

Scheduling

in

Proc

IEEE

INFOCOM

-LSB-

-RSB-

K.

Brown

and

S.Singh

M-TCP

TCP

for

Mobile

Cellular

Networks

ACM

Computer

Communications

Review

Vol

-LRB-

-RRB-

-LSB-

-RSB-

A.

Canton

and

T.

Chahed

End-to-end

reliability

in

UMTS

TCP

over

ARQ

in

proceedings

of

Globecomm

-LSB-

-RSB-

Mobile

Station

Base

Station

Compatibility

Standard

for

Dual-Mode

Wideband

Spread

Spectrum

Cellular

Systems

Washington

Telecommunication

Industry

Association

-LSB-

-RSB-

G.

Holland

and

N.

H.

Vaidya

Analysis

of

TCP

Performance

over

Mobile

Ad

Hoc

Networks

in

Proceedings

of

ACM

Mobicom

-LSB-

-RSB-

H.

Inamura

et

al.

TCP

over

G

and

Wireless

Networks

Aug.

-LSB-

-RSB-

F.

Khafizov

and

M.

Yavuz

TCP

over

networks

Internet

Draft

-LSB-

-RSB-

T.

V.

Lakshman

and

U.

Madhow

The

Performance

of

Networks

with

High

Bandwidth-delay

Products

and

Random

Loss

in

IEEE/ACM

Transactions

on

Networking

Jun.

-LSB-

-RSB-

R.

Ludwig

et

al.

Multi-layer

Tracing

of

TCP

over

a

Reliable

Wireless

Link

in

Proceedings

of

ACM

SIGMETRICS

-LSB-

-RSB-

Reiner

Ludwig

and

Randy

H.

Katz

The

Eifel

Algorithm

Making

TCP

Robust

Against

Spurious

Retransmissions

in

ACM

Computer

Communications

Review

Vol

No.

-LSB-

-RSB-

V.

Misra

W.

Gong

and

D.

Towsley

Stochastic

Differential

Equation

Modeling

and

Analysis

of

TCP

Windowsize

Behavior

in

Proceedings

of

Performance

-LSB-

-RSB-

P.

Narvaez

and

K.-Y

Siu

New

Techniques

for

Regulating

TCP

Flow

over

Heterogeneous

Networks

in

LCN

-LSB-

-RSB-

Modeling

TCP

Throughput

a

Simple

Model

and

its

Empirical

Validation

in

Proceedings

of

SIGCOMM

-LSB-

-RSB-

S.

Paul

et

al.

An

Asymmetric

Link-Layer

Protocol

for

Digital

Cellular

Communications

in

proceedings

of

INFOCOM

-LSB-

-RSB-

Third

Generation

Partnership

Project

RLC

Protocol

Specification

-LRB-

TS

:-RRB-

-LSB-

-RSB-

TIA/EIA/IS

Data

Service

Options

for

Spread

Spectrum

Systems

Radio

Link

Protocol

Type

January

-LSB-

-RSB-

S.

Karandikar

et

al.

TCP

rate

control

in

ACM

Computer

Communication

Review

Jan

-LSB-

-RSB-

Partnership

Project

Release

-LSB-

-RSB-

Microwave

mobile

communications

edited

by

W.

C.

Jakes

Wiley

-LSB-

-RSB-

Delays

in

the

HDR

System

QUALCOMM

Jun.

-LSB-

-RSB-

R.

Jain

The

Art

of

Computer

Systems

Performance

Analysis

Wiley

-LSB-

-RSB-

J.

Padhye

and

S.

Floyd

On

Inferring

TCP

Behavior

in

Proceedings

of

SIGCOMM

network
tcp
3g wireless
algorithm
wireless communication
design
architecture

performance evaluation
prediction model
link and rate variation
simulation result
congestion solution
3g wireless links