joint beats/wip seminar, june 6, 2003 copyrights saverio mascolo rate-based control for streaming...

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo

Rate-based Control for Rate-based Control for Streaming Videos over Streaming Videos over

the Internetthe Internet

Saverio MascoloSaverio MascoloDipartimento di Elettrotecnica ed Dipartimento di Elettrotecnica ed

ElettronicaElettronicaPolitecnico di Bari – ItalyPolitecnico di Bari – Italy

JOINT BEATS/Wireless IP seminar, JOINT BEATS/Wireless IP seminar,

Hotel Alexandra, Loen, June 4 – 6, 2003Hotel Alexandra, Loen, June 4 – 6, 2003


OutlineOutline

IntroductionIntroduction Data and videosData and videos Protocols at the transport layer: TCP Protocols at the transport layer: TCP

vs. UDPvs. UDP Rate-based vs. window-basedRate-based vs. window-based TFRC proposal TFRC proposal ARC (our proposal)ARC (our proposal) SimulationsSimulations


LayeringLayering

Application layerApplication layer Transport layer (TCP/UDP)Transport layer (TCP/UDP) Network layer (IP)Network layer (IP) Link layerLink layer Physical layerPhysical layer


IntroductionIntroduction Up to now, Up to now, the the most part of Internet traffic is most part of Internet traffic is still still due due

to data (ftp, web pages…)to data (ftp, web pages…)

However, the part of Internet traffic due to audio and However, the part of Internet traffic due to audio and video streaming is ever increasingvideo streaming is ever increasing

TCPTCP/IP/IP has been quite effective has been quite effective for data but it is not for data but it is not appropriate for audio/videosappropriate for audio/videos

Application Data

Advertised Window

TCP/IP

Receive Socket Buffer

TCP/IP

Application Data

TCP flows

bufferTCP/IPi

TCP/IPj

TCP/IPk

TCP/IPm

Send Socket Buffer

TCP/IP NetworkTCP/IP Network

Internet is a black box


Data vs. VideosData vs. Videos

Data and videos have different Data and videos have different requirements:requirements: Data Data

Need reliable deliveryNeed reliable delivery Not senstive to delays, jitter delaysNot senstive to delays, jitter delays

Videos Videos Not need reliable delivery (a low Not need reliable delivery (a low

percentage of lost packet can be tolerated)percentage of lost packet can be tolerated) Senstive to delays, jitter delaysSenstive to delays, jitter delays


Why TCP is not effective for videos?Why TCP is not effective for videos?

TCP is bursty because it is window basedTCP is bursty because it is window based TCP/IP provides reliable delivery but does not TCP/IP provides reliable delivery but does not

guarantee delays and jitter guarantee delays and jitter As a consequence, As a consequence, audio and videos are streamed audio and videos are streamed

over the UDP protocolover the UDP protocol, which is not reliable and do , which is not reliable and do not perform congestion controlnot perform congestion control

… … the Internet will experience congestion collapse the Internet will experience congestion collapse unless congestion control is implemented at theunless congestion control is implemented at the transport layer or at thetransport layer or at the application layer application layer


State of the art: TFRCState of the art: TFRC To preserve Internet stability, congestion control To preserve Internet stability, congestion control

should be should be used used for videos for videos ((standardizedstandardized congestion congestion control such as in the case of TCP for data ?)control such as in the case of TCP for data ?)

A lot of literature availableA lot of literature available

Current leading proposal: Transport Friendly Rate Current leading proposal: Transport Friendly Rate Control (TFRC) by S. Floyd et al. Control (TFRC) by S. Floyd et al.


ReferencesReferences TCP Friendly Rate Control (TFRC): Protocol SpecificatTCP Friendly Rate Control (TFRC): Protocol Specificat

ionion..Handley, M., Floyd, S., Pahdye, J., and Widmer, J.Handley, M., Floyd, S., Pahdye, J., and Widmer, J.RFC 3448, Proposed Standard, January 2003. RFC 3448, Proposed Standard, January 2003.

Equation-Based Congestion Control for Unicast Equation-Based Congestion Control for Unicast ApplicationsApplications Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer.Widmer. SIGCOMM 2000. SIGCOMM 2000.

ftp://ftp.isi.edu/in-notes/rfc3448.txt

ftp://ftp.isi.edu/in-notes/rfc3448.txt


TFRCTFRC The basic idea is to The basic idea is to employ the long-term throughput employ the long-term throughput

equation of TCP proposed in Padhye et al., equation of TCP proposed in Padhye et al., "Modeling "Modeling the the TCP Throughput", Proc. Sigcomm TCP Throughput", Proc. Sigcomm 1998, in order to provide an input rate smoother than 1998, in order to provide an input rate smoother than TCPTCP::

)321(*8/33*_3/2 2pbppRTOtbpR

sX


where…where…

X X == transmit rate transmit rate [[bytes/secondbytes/second]]

ss== packet size in bytes packet size in bytes

RR== round trip time in seconds round trip time in seconds

pp== loss event rate loss event rate

t_RTOt_RTO== TCP retransmission timeout TCP retransmission timeout=4R=4R

b= #ofb= #of packets acknowledged by a single TCP packets acknowledged by a single TCP acknowledgementacknowledgement


What is important from What is important from the transport layer point the transport layer point

of viewof view The formula shows that what TCP “sees” is the The formula shows that what TCP “sees” is the

packet error ratepacket error rate Thus it is important that the physical layer and link Thus it is important that the physical layer and link

layer (ARQ+FEC) do a good job!layer (ARQ+FEC) do a good job! In fact,In fact, TCP assumes reliable link=>interprets packet TCP assumes reliable link=>interprets packet

loss as indication of congestionloss as indication of congestion Further improvements can be obtained using Further improvements can be obtained using

modified version of modified version of the the TCP TCP stack stack such as Westwoodsuch as Westwood


Rationale ofRationale of TFRC TFRC

The use of the long-term equation aims at The use of the long-term equation aims at providing the following advantages:providing the following advantages:

1)1) Eliminate the Eliminate the burstinessburstiness of TCP due its window- of TCP due its window-based naturebased nature

2)2) ProvideProvide an algorithm an algorithm friendlyfriendly toward TCP, i.e. toward TCP, i.e. TFRC and TCP MUST coexist getting a fair TFRC and TCP MUST coexist getting a fair bandwidth share. (friendliness is clearly a bandwidth share. (friendliness is clearly a primary concern when proposing a new CC algo)primary concern when proposing a new CC algo)


Our criticismOur criticism The long-term equation approximates the TCP The long-term equation approximates the TCP

throughput (30% error and more), but this is not the throughput (30% error and more), but this is not the main problem…main problem…

Thus, differently from what Thus, differently from what is is affirmed in literature, affirmed in literature, we have found that we have found that TFRC is not friendly towards TFRC is not friendly towards TCPTCP


Our proposal: The Our proposal: The adaptive rate control adaptive rate control

(ARC) alghorithm(ARC) alghorithm Main ideas: Main ideas:

control theoretical analysis to design a control theoretical analysis to design a rate-based version of TCP congestion rate-based version of TCP congestion control control

end-to-end bandwidth estimation end-to-end bandwidth estimation a la a la WestwoodWestwood


Control analysis Control analysis background background

One starting point is the paper:One starting point is the paper:

S. Mascolo, “Congestion Control using the S. Mascolo, “Congestion Control using the Smith principle” Automatica, Dec. 1999Smith principle” Automatica, Dec. 1999


Without loss of generality the control scheme can be Without loss of generality the control scheme can be reduced to a reduced to a Smith PredictorSmith Predictor+proportional +proportional controllercontroller

xij(t)Gci(s)

ui(t)

dij(t)

ri(t)

+ _k

_

fwTs

e

s

1

s

iRTTse

s

1

fbTs

e

Control lawControl law Rate- basedRate- based

Window-basedWindow-based

W=AdvertisedWindow – OutstandingPackets W=Cwnd – OutstandingPackets

(this is the classic sliding window control)

du TtxTtrktut

RTTtfbfb

)()(()( )


Bandwidth estimate Bandwidth estimate a la a la WestwoodWestwood

The other starting point is the paper:The other starting point is the paper:

S. Mascolo et al , “TCP Westwood: S. Mascolo et al , “TCP Westwood: e2e bandwidth estimation for TCP e2e bandwidth estimation for TCP congestion control” , ACM Mobicom 01congestion control” , ACM Mobicom 01

TCP WestwoodTCP Westwood

Congestion Avoidance

Slow start

cwnd

time

Timeoutssthresh

BWE*RTTmin

Adaptive setting cwnd=ssthr=BWE*RTTmin

key feature: window shrinking after congestion based on the measured available bandwidth


The ARC algorithmThe ARC algorithm

To provide friendliness towards TCP, we properly set w(t) to mimic the slow-start and congestion avoidance phase of TCP.

When a congestion episode happens w(t)

is reduced a la Westwood TCP, that is,

w(t)=B*(RTTmin+1/k)

to ensure the depletion of the queues along the path


TFRC vs. ARC: main TFRC vs. ARC: main differencesdifferences

TFRC employs a long-term equation TFRC employs a long-term equation =>=> it isit is not friendly towards Reno not friendly towards Reno

ARC employs a dynamic equation ARC employs a dynamic equation => it is responsive and friendly to => it is responsive and friendly to RenoReno


Single Bottleneck Single Bottleneck ScenarioScenario

RTTs:RTTs:

N Reno sources: 250/N-250msN Reno sources: 250/N-250ms

UDP source: 250msUDP source: 250ms

M Rate based sources: 250/M-250ms- 10 Reno Backward M Rate based sources: 250/M-250ms- 10 Reno Backward connections: 25-250msconnections: 25-250ms

N Reno

sources

UDP

source

M Rate

sources

10 Reno

Sinks

R1 R2

N Reno

Sinks

UDP

Sink

M Rate

Sinks

10 Reno

sources

Forward Traffic

Backward Traffic


1 Reno TCP and 1 ON-OFF UDP source 1 Reno TCP and 1 ON-OFF UDP source over a 2Mbps bottleneck-over a 2Mbps bottleneck-

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

Without Reverse traffic With Reverse traffic

TCP is bursty due to ACK compression and window-based control.

Notice that a piece-wise constant available bandwidth reproduces the case of bandwidth

oscillation in 2.5g/3G wireless systems(see Khafizov et al. “Running TCP over IS-2000”,

ICC02)


1 TFRC and 1 ON-OFF UDP source over a 1 TFRC and 1 ON-OFF UDP source over a 2Mbps bottleneck2Mbps bottleneck


TFRC provides a smoothed sending rate w.r.t. Reno TCP

0

100000

200000

300000

400000

500000

600000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

0

100000

200000

300000

400000

500000

600000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)


1 ARC and 1 ON-OFF UDP source over a 1 ARC and 1 ON-OFF UDP source over a 2Mbps bottleneck2Mbps bottleneck


ARC is not sensitive to congestion along the backward path and provides a smoother sending

rate w.r.t. Reno TCP

0

100000

200000

300000

400000

500000

600000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

0

100000

200000

300000

400000

500000

600000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

TFRC promptly reacts to bandwidth variations

1000

10000

100000

1000000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

1000

10000

100000

1000000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

ARC promptly reacts to bandwidth variations and

is fairer than TFRC

1000

10000

100000

1000000

0 200 400 600 800 1000

s

Tra

nsm

issi

on r

ate

(Byt

es/s

)

Reno TCP exhibits huge burstyness

10 connections 10 connections and 1 ON-OFF and 1 ON-OFF UDP source over UDP source over a 10Mbps a 10Mbps bottleneckbottleneck


Many Connections over a 10Mbps Many Connections over a 10Mbps bottleneckbottleneck

ARC and TFRC improves bottleneck utilization w.r.t Reno TCP at low levels of statistical

multiplexing

1.14E+061.15E+061.16E+061.17E+061.18E+061.19E+061.20E+061.21E+061.22E+061.23E+061.24E+061.25E+06

20 50 80 110 140 170 200No. of connections

Goo

dput

(B

ytes

/s)

91

92

93

94

95

96

97

98

99

100

Bot

tlen

eck

Uti

liza

tion

(%

)

TFRCARCReno TCP


Multihop ScenarioMultihop Scenario

RTTs:RTTs:C1 connection: 250ms; Cross traffic connections: 50msC1 connection: 250ms; Cross traffic connections: 50msStart time:Start time:C1:10s; Cross Traffic: 0s.C1:10s; Cross Traffic: 0s.Link Link CapacitiesCapacities:: 1Mbps 1Mbps

C1Sink1

C2

R

Sink2

C3Sink3

R R

C5Sink5

R

C4 Sink4

1th hop 2th hop


Homogeneous scenario (all Homogeneous scenario (all sorces controlled by the sorces controlled by the

same algorithm)same algorithm)

N.B. TFRC does not allow the C1 connection to grab its bandwidth share=>TFRC IS NOT FAIR

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05

1 2 3 4 5 6 7 8 9 10Number of hops

Goo

dput

of

the

C1

conn

ecti

on

(Byt

es/s

)

ARCTFRCReno TCPFair Share

Reno C1 connection and Reno C1 connection and different type of cross-different type of cross-

traffictraffic

TFRC cross-traffic does not allow C1 Reno connection to grab its bandwidth share, i.e.,

TFRC IS NOT FRIENDLY TO RENO

1.E+00

1.E+01

1.E+02

1.E+03

1.E+04

1.E+05

1 2 3 4 5 6 7 8 9 10Number of hops

Goo

dput

of

the

C1

conn

ecti

on

(Byt

es/s

)

ARC cross traffic

TFRC cross traffic

Reno TCP cross traffic

Fair Share


Reno cross-traffic, C1 Reno cross-traffic, C1 Reno or TFRC or ARCReno or TFRC or ARC

1.E+03

1.E+04

1.E+05

1 2 3 4 5 6 7 8 9 10Number of hops

Goo

dput

of

the

C1

conn

ecti

on

(Byt

es/s

)

ARCTFRCReno TCPFair Share

joint beats/wip seminar, june 6, 2003 copyrights saverio mascolo rate-based control for streaming...

Documents

ratebased control

tcp throughput

case of tcp

tcp retransmission timeout

streaming videos

reliable delivery

internet traffic

congestion collapse