Multipath Live Streaming via TCP: Scheme,Performance and Benefits∗
Bing Wang University of Connecticut
Wei Wei
United Technologies Rearch
Center
Zheng Guo University of Connecticut
Don Towsley University of Massachutts,
Amherst
ABSTRACT
Motivated by the wide u of TCP for streaming in prac-tice and the increasing availability of multipath between end hosts,we study multipath live streaming via TCP in this pa-per.Wefirst design a simple and practical TCP-bad multi-path streaming scheme,named Dynamic MPath-streaming (
DMP-streaming),which dynamically distributes packets over multiple paths by implicitly inferring the available bandwidths on the paths.To allow systematic performance study,we develop an analytical model for DMP-streaming and validate the model using extensive ns simulation and In-ternet experiments.We explore the parameter space of this model andfind that DMP-streaming generally provides sat-isfactory performance when the aggregate achievable TCP throughput is1.6times the video bitrate,with a few conds of startup delay.Last,we comment on the benefits of using multipath versus single path for TCP-bad streaming. 1.INTRODUCTION
The increasing availability of multipath between end hosts has motivated a number of recent studies on mul-tipath audio/video ,streaming over mul-tiple network paths)[11,3,19,22,26].All the studies assume UDP as the transport protocol.Indeed,TCP is conventionally regarded as inappropriate for multi-media streaming,since its backoffand retransmission ∗This work was supported in part by UCONN large grant, and the National Science Foundation under ANI-0325868, ANI-0240487,ANI-0085848,and EIA-0080119.
Permission to make digital or hard copies of all or part of this work for personal or classroom u 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 thefirst page.To copy otherwi,to
republish,to post on rvers or to redistribute to lists,requires prior specific permission and/or a fee.
CoNEXT’07,December10-13,2007,New York,NY,U.S.A. $hanisms may lead to long delays which violate the realtime requirement of multimedia streaming.
In this paper,defying the conventional wisdom,we study an approach that relies on TCP for multipath streaming.This is motivated by the wide u of TCP for streaming in practice and our earlier results on single-path TCP streaming[31].TCP streaming is widely supported in commercial streaming ,Real Media and Windows Media).Furthermore,recent mea-surement studies have shown that,for both stored-video and live streaming,a significant fraction of the traffic (around or above50%)us HTTP/TCP[33,28,29]. In our earlier work[31],we studied the performance of single-path TCP streaming and found that its per-formance is generally satisfactory when the achievable TCP throughput is roughly twice the media bitrate, with a few conds of startup delay.This result partly explains why TCP streaming has been an attractive op-tion in practice:such a bandwidth requirement can be satisfied even for broadband home urs(using cable modem or ADSL technologies)for a large fraction of streaming multimedia clips in the Internet today. Motivated by the above obrvations,we focus on multipath live streaming via TCP.More specifically,we consider the s
cenario in which a video rver generates content in real time and streams it via TCP to a client over K paths.The K paths may or may not share bottleneck links.We ek to answer the following ques-tions:Under what circumstances can multipath TCP-bad live streaming provide satisfactory performance? What are the benefits from using multiple paths,com-pared to using a single path,in TCP-bad live stream-ing?
Our paper answers the above questions and makes the following main contributions:
•We design a simple and practical scheme,named Dynamic MPath-streaming(DMP-streaming),for multipath streaming via TCP.It dynamically dis-
tributes packets over the multiple paths(to ac-
commodate bandwidthfluctuations)by implicitly
inferring the available bandwidths on the paths.
•We develop an analytic model for DMP-streaming.
This model allows a systematic performance study,
a task that is difficult when using empirical mea-
surements or simulation alone.We validate this
model using extensive ns simulation and Internet
experiments.To the best of our knowledge,this is
秋季运动会加油稿大全thefirst analytical model on multipath streaming
via TCP.
•We systematically vary the parameters in this model to explore the parameter space when using two
paths in DMP-streaming.Wefind that the perfor-
mance of DMP-streaming is not nsitive to path
heterogeneity.Furthermore,the performance is
generally satisfactory when the aggregate achiev-
able TCP throughput is1.6times the video bi-
trate,with a few conds of startup delay.
Our results help answer the following two important questions on TCP-bad streaming:(i)If a video bi-trate is satisfied by a single path,can two paths,each with half of the achievable TCP throughput of the single path,support the same video bitrate?When the access link is the bottleneck,this question transforms to:can a high bandwidth access link be replaced by two lower bandwidth links while maintaining the same streaming performance?(ii)If a video bitrate is satisfied by a sin-gle path,can two such paths support videos with twice the bitrate?When the access link is the bottleneck,this question transforms to:if a ur subscribes to two ac-cess networks of similar ,ADSLs from two different providers),can he/she view videos with bitrates twice as tho supported by a single access net-work?
Our results indicate that the answer to both of the above questions is:yes.This is becau,multipath TCP streaming provides satisfactory performance when the ratio of the aggregate achievable TCP throughput over the video bitrate exceeds1.6,lower than the ratio of 2in single-path TCP streaming[31].Therefore,for question(i),two paths,each with half of the achievable TCP throughput of
the single path,can support the same(even higher)video bitrate supported by the single path;for question(ii),two paths,each with the achiev-able TCP throughput of the single path,can support videos with twice(even more than twice)the bitrate supported by the single path.Hence,in addition to eco-nomical reasons(subscribing to multiple low-bandwidth access links is cheaper than subscribing to a single high-bandwidth access link[12]),it is also advantageous to u multipath for TCP-bad streaming due to perfor-mance reasons.
The rest of the paper is organized as follows.Sec-tion1.1summarizes related work.Section2describes the problem tting.Sections3and4prent DMP-streaming and its analytical model respectively.Sec-tions5and6describe validation of the model using ns simulations and Internet experiments,respectively. Section7explores the parameter space of the model. Finally,Section8concludes the paper.
1.1Related work
Multipath continuous media streaming is studied in[11, 3,19,22,26,15,6].In particular,[11,26]demon-strate the benefits of using multiple paths for contin-uous media streaming.In[3,19],coding techniques (Multiple Description Codes)are applied to the video streams to improve loss recovery.Th
e study in[22]de-termines the nding rate and the distribution of pack-ets on the multiple paths to minimize loss rate at the receiver.The work in[15]propos a heuristic algo-rithm for multipath video streaming that provides clo to optimal performance.The study in[6]propos a multipath streaming scheme suitable for cellular links. All the above studies u UDP as the transport pro-tocol.We study multipath streaming via TCP,which is fundamentally different from UDP-bad streaming (e.g.,a UDP-bad streaming might not u error re-covery and/or congestion control mechanisms;even if it us,the mechanisms are very different from tho in TCP).To the best of our knowledge,our work is the first study on multipath streaming via TCP.Our per-formance study focus on wired networks(although DMP-streaming can be applied to wireless networks). Using TCP for multimedia streaming eliminates the need for error-recovery at the application-level and au-tomatically provides TCP-friendliness.Furthermore, it is more likely to pass throughfirewalls in practice. The advantages have motivated a number of studies on TCP-bad streaming.The studies of[27,17,8,7] focus on how to adapt the video bitrate to deal with network bandwidthfluctuations.Our earlier work[31] studied the performance of multimedia streaming using TCP.A recent study[16]analytically determines the proper receiver buffer size to ensure a prescribed video quality for TCP streaming.All the above studies u one TCPflow on a single path,while we u multiple TCPflows in this paper.
The literature on TCP modeling is extensive.Much of the TCP modeling focus on TCP performance for file transfers,assuming long-livedflows[20,24,23,2,10] or short-livedflows[5,21].The study of[4]models TCP congestion window to determine a TCP-friendly trans-mission rate for UDP videoflows.Our study differs from the above in that we develop analytical models for multipath TCP streaming,with a focus on multipath and the timeliness of the packets.
Last,[13]points out veral limitations of using TCP over multiple paths for reliable data transfer when the access network has high bandwidthfluctuations.Our study is in the context of wired network(which has relatively stable bandwidth)for multimedia streaming (which can tolerate certain amount of packet loss). 2.PROBLEM SETTING
Suppo that a client is connected to a rver using K
paths(K≥2),indexed1to K.The paths are formed using a multipath ,multihoming of the end hosts).They may or may not share bottleneck links (a special ca is that they are the same path).We con-sider live streaming,that is,the rver generates video content in real time and is only able to transmit con-tent that has already been generated.The rver opens
K TCP connections,one on each path,and stripes the generated video packets using the multiple TC
Pflows
to the client.Each packet is associated with a packet number(corresponding to the position,and hence the playback time,of the packet)so that packets from the multiple paths can be reasmbled at the receiver.The client allows a startup delay,τ,that is on the order of conds,a common practice in commercial streaming products.All packets arriving earlier than their play-back times are stored in the client’s local buffer,which is assumed to be sufficiently large so that no packet is lost
at the client side.This assumption is reasonable since modern machines are equipped with a large amount of storage.
We consider a constant bit rate(CBR)video,moti-vated from measurement results that most videos streamed over the Internet are CBR[18].Letµdenote the play-back rate of the video(in packets per cond).For simplicity,all packets are assumed to be of the same size.For analytical tractability,we assume continuous playback at the client.A packet arriving later than its playback time is referred to as a late packet.A late packet typically leads to a glitch during playback. Therefore,we u the fraction of late ,the probability that a packet is late,as our performance metric.Strictly speaking,the fraction of late packets does not correspond directly to viewing quality,since human per
ception tolerates occasional glitches in the playback.However,we are not aware of any quanti-tative metric that directly corresponds to the viewing quality perceived by a human.We therefore u the fraction of late packets to roughly measure streaming performance.
We next describe two characteristics of live stream-ing.Thefirst is on the number of early , packets arriving earlier than their playback times);the cond is on the TCP throughputs on the multiple paths.
2.1Number of early packets in live streaming
少先队入队誓词
Time
P
a
c
k
e
t
n
u
m
b
e
W
r
PW
P
l
a
y
b
a
c
k
G
e
n
e
r
a
t
i
o
n
L
a
t
e
p
a
c
k
e
t
s
A
r
r
i
v
a
l
Figure1:Illustration of multipath live stream-ing via TCP.In this example,K=2,solid and dashed curves reprent packet arrivals from the first and the cond path respectively.
Fig.1illustrates multipath live streaming via TCP. The video rver generates packets at the constant rate equal to the playback rate of the ,µpackets per cond).For ea of exposition,we assume that packets are generated from time0,starting with packet number0.Let G(t)denote the number of packets gen-erated at the rver by time t.Then G(t)=µt.At the client side,let B(t)denote the number of packets played back by the client by time t.Then B(t)=µ(t−τ), t≥τ.Obrve that G(t)−B(t)=µτ.Since only packets that are generated can be transmitted,the to-tal number of packets arriving at the client by time t is at most G(t).Therefore,the number of early packets is at most G(t)−B(t)=µτat any time t.This char-acteristic is to be ud in our model for multipath live streaming via TCP in Section4.
2.2TCP throughputs in live streaming
Letσk denote the average achievable TCP through-put(in packets per cond)on path k,which is the throughput achieved by a backlogged TCP ,
a source always having data to transmit.Letσ
k
可爱的个性签名denote the average TCP throughput(in packets per cond)
on path k in live streaming.Thenσ
k
≤σk becau the TCP source on the k-path may not always have data to nd(data are generated in real-time and only
generated packets can be transmitted).Furthermore, K
i=1
σ
网球发球规则
k
≤µsince the packet generation rate isµ. 3.SCHEME FOR MULTIPATH STREAM-
ING VIA TCP
In live-streaming,to reduce the number of late pack-ets,the rver needs to transmit the generated packets to the client as fast as allowed by the TCPflows on the multiple paths.This is becau,network conges-tion may cau the aggregate TCP throughput to be
At the video rver:
Generate packets
Place the generated packets into rver queue
At a TCP nder:
If(it can nd packets){
if(it obtains access to the rver queue){
do{
Fetch packets from the head of the rver queue }till(it cannot nd or the rver queue is empty) }
}
Figure2:DMP-streaming:actions of the video rver and the TCP nders.
as的六种用法occasionally lower than the video playback rate;buffer-ing as many packets as possible can compensate this adver effect.A key question in multipath streaming is:given the multiple paths,which path should a packet be assigned to?
Intuitively,a desired streaming scheme allocates pack-ets over the multiple paths dynamically according to their current network bandwidths and allocates more packets on paths with higher throughputs(as in existing UDP-bad ,[25]).Furthermore,it should avoid explicitly probing for bandwidth on each path(so no probing traffic is generated).We develop a TCP-bad streaming scheme that satisfies the above de-sired properties and name it Dynamic MPath-streaming (DMP-streaming).We next describe this scheme in de-tail.
Our DMP-streaming scheme is summarized in Fig.2. The rver places the generated video packets into a queue,referred to as rver queue.In the rver queue, packets with earlier playback times are placed at the head of the queue.The TCP nders on each of the paths can fetch packets from the rver queue.How-ever,at a certain point of time,only one TCP nder is allowed to access the rve
r queue(this can be achieved through a locking mechanism).More specifically,when a TCP nder can nd data,itfirst obtains the access to the rver queue,and then fetches packets from the head of the rver queue until it cannot nd any more ,this TCP nder is blocked)or when no packet is inside the rver queue.At that time,it re-leas its lock on the rver queue so that another TCP source can access the rver queue.
We now demonstrate that DMP-streaming has the desired properties that are described earlier.First,it clearly allocates packets in a dynamic manner over the multiple paths(each TCP source fetches packets dy-namically from the rver queue).Second,it allocates more packets to the paths with higher achievable TCP throughputs by implicitly inferring the achievable TCP throughputs on the paths.This can be explained as follows.In the current implementation of TCP,a TCP nder places packets in the its nding buffer before transmitting them into the network.The TCP nder cannot nd any more ,the TCP nder blocks)when the nding buffer is full.Therefore,once the TCP nding buffers on the multiple paths become full after the initial transient period,a path with a higher achievable TCP throughput drains packets from its nding buffer faster and fetches more packets from the rver queue.Therefore,a TCP source on a path with a higher achievable throughput nds a larger frac-tion of the packets.
As we can e,DMP-streaming is extremely simple —it takes advantage of the congestion control mecha-nisms in TCP to adapt to bandwidthfluctuations in the network paths.It can be ud when the multiple TCP flows share or do not share bottleneck links(a special ca is that they share the same path).Furthermore,it is also applicable to stored-video streaming.We focus on using DMP-streaming for live streaming in this pa-per;its performance for stored-video streaming is left as future work.
4.ANALYTICAL MODEL
We develop a continuous-time Markov model for DMP-streaming.As we shall e,this model allows us to sys-tematically vary the various parameters to explore the performance of DMP-streaming(Section7).In the fol-lowing,wefirst provide an overview of our model and then describe our model in detail.
4.1Overview of the model
Our model assumes a single TCPflow on each path from the rver to the client.It is developed by con-sidering the data production and consumption at the client-side buffer:the multiple TCP connections from the rver to the client produce(transmit)packets and store them in the client-side buffer;the client starts to ,play back)packets in the buffer from time τat a constant rate of
µpackets per cond.We add the constraint that a producer stops producing packets when there are N max=µτearly packets in the buffer. This follows from an earlier obrvation that the num-ber of early packets in the client-side buffer never ex-ceeds N max=µτ(e Section2.1).
One challenge in modeling multipath TCP streaming is that,although packets from each path arrive in order, packets from the multiple paths may arrive out of order. For instance,suppo that packet i is lost by a TCPflow and a later packet,packet j(j>i),is nt successfully by another TCPflow.Then packet j may arrive at the client earlier than packet i and this leads to out-of-order packets at the receiver.One way to deal with out-of-order packets is to include the packet number of each packet in the model.However,this will make the state space of the model prohibitively large and render the
model intractable.On the other hand,as confirmed by our simulation and experimental results(in Sections5 and6),out-of-order packets only have a negligible effect on the fraction of late packets in DMP-streaming.In other words,playing back packets in their arriving order only caus a negligible error.Therefore,in our model, we only keep track of the number of early packets and play back packets as if they were in order.The reasons why the effect of out-of-order packets is negligible can be explained by considering the following two cas.In both cas,we consider an arbitrary packet,i,arriving on path k.
•Ca1:packet i is not ,it arrives earlier than its playback time).Suppo packet j(j>i) arrives earlier than packet i.Then when playing back packets in their arriving order,packet j is played back as packet i.This ca,however,does not cau an error to the fraction of late packets (since neither of packets i and j is late).
•Ca2:packet i is ,path k is congested).
In particular,suppo a quence of n packets on path k are late(n≥1).If there are out-of-order packets and packets are played back in their ar-riving order,packets from another path may be played back as the n packets and this caus an error.However,when this happens,we expect n to be very small and hence the error is negligi-ble.This is becau DMP-streaming reduces the number of packets nt on a path when the path becomes congested.Since the startup delays are much longer than the round-trip times of the TCP flows(a few conds versus a few hundred millic-onds),we expect the number of packets nt on a congested path to have been reduced significantly
(i.e.,n is small)when late packets occur.
4.2Model for DMP-streaming
Let(X1(t),...,X K(t),N(t))reprent the state of the model for DMP-streaming at time t,where X k(t)is the state of the k-th TCPflow and N(t)is the number of early packets in the client’s local buffer at time t, k=1,...,K,t≥0.The state transition of the model is governed by the state transitions of the various TCP flows and the packet consumption event.In the follow-ing,wefirst describe the state transition for each TCP flow.We then describe the evolution of N(t)and how to obtain the fraction of late packets from the model. The state transitions of the different TCPflows are independent of each other.For the k-th TCPflow,its state at time t,X k(t),is a tuple containingfive ,X k(t)=(W k(t),C k(t),L k(t),E k(t),Q k(t)), where W k(t)is the window size;C k(t)models the de-layed ACK behavior of TCP(it changes from0to1 or from1to0after a state transition);L k(t)is the number of packets lost in the previous round;E k(t)de-notes whether the connection is in a timeout state and the value of the back-offexponent;Q k(t)indicates if a packet being nt in the timeout pha is a retransmis-sion(Q k(t)=1)or a new packet(Q k(t)=0).The transition rate from one state to another state depends
on the two states and the parameters of this TCP
flow,including its RTT,loss rate and timeout value.1 Due to space limits,a detailed description of the state transition rate for each TCPflow is found in[32].
We now describe how the number of early packets,
N(t),evolves over time.The state of the Markov chain changes under two types of events:(1)when any of the TCPflows makes a transition,(2)when a packet is consumed(played back)from the client’s local buffer. Thefirst type of events increas N(t)while the cond type of events decreas N(t).To satisfy the constraint that N(t)≤N max=µτin live streaming(e Sec-tion2.1),a TCPflow does not make a transition if the current number of early packets is N max.Let E(t)de-note the event that triggers the transition at time t. Let E(t)=P denote that a transition of a TCPflow triggers the transition at time t.Similarly,let E(t)=C denote that a packet consumption triggers the transi-tion at time t.Then considering the two conditions,•Condition1(E(t)=P):Suppo the k-th TCP
flow triggers the transition.Then the number of
early packets,N(t),is incread by S k(t)(not ex-
ceeding N max=µτ),where S k(t)is the number
of packets that the k-th TCPflow transmits suc-
cessfully at the transition(details in[32]).
奥妙的意思•Condition2(E(t)=C):then the number of early
packets,N(t),is reduced by1.
Note from the above that,in our model,aflow with
a higher achievable throughput contributes more early packets,and hence captures the property of DMP-streaming that such aflow transmits a larger fraction of packets.
苹果闹钟怎么设置For sufficiently long videos,we obtain the fraction of late packets from the stationary distribution of N(t)as f=lim
t→∞
P(N(t)<0|E(t)=C).(1) We numerically solve for the stationary distribution of
N(t)using TANGRAM-II modeling tool[9].
The above model assumes that loss events over the multiple paths are independent.This is true when the TCPflows do not share bottleneck links.When the TCPflows share bottleneck links,as long as the loss
in the TCPflows are not significantly correlated,our model may still provide accurate results.We validate
1Our assumption on loss process follows[23,10].That is, packet loss in different RTTs are independent and packet loss in the same RTT are correlated(if a packet is lost,all remaining packets until the end of the RTT are lost).Last,
the effect of lost ACKs is regarded as negligible.
Config.FTP HTTP Prop.Delay B.w.Buffer
flowsflows(ms)(Mbps)(pkts) 194040 3.750
29401 3.750
3194040 5.050
45201 5.030
Table1:Configurations of the bottleneck link. our model when the TCPflows share and not share bottleneck links in Section5.
5.MODEL V ALIDATION USING NS
In this ction,we validate our model for DMP-streaming using ns.We u K=,two TCPflows are ud for live streaming.In the following,wefirst describe our methodology for validation and then describe the validation results.
5.1Methodology
We refer to the TCPflows that are ud to stream video as video streams.The network is simulated as fol-lows.Each video stream travers a path with a bottle-neck link.This bottleneck link is also ud by multiple FTP and HTTPflows(referred to as backgroundflows). We simulate four different configurations for the bottle-neck link on a path,by varying the delay,bandwidth and buffer size at the link and the number of back-groundflows traversing that link.The configurations are listed in Table1.
For the video stream(via TCP)on the k-th path,let
p k,R k and R k
T O denote respectively the loss probabil-
ity,the round-trip time(RTT),and thefirst retrans-
mission timer.We further define T O
k =R k
T O
/R k;T O
k
reflects the variation of the RTTs.In all cas,the video streams us TCP Reno.We are interested in the steady-state behavior of multipath streaming and t the video length to10,000conds.The startup delay ranges from4to10conds.
In each tting,we make30runs.Let f m and f s denote the average fraction of late packets from the model and the simulation respectively.We say that the model and the simulation match well if one of the following two conditions is satisfied:f m falls within the confidence interval obtained from the simulation, or0.1<f m/f s<10.The reason for the cond con-dition is as follows.When f m and f s lie within the same order
of magnitude of each other,we regard that they correspond to similar viewing quality(the qual-ity is classified as either satisfactory or unsatisfactory since our ultimate goal is to determine the conditions under which TCP provides satisfactory streaming per-formance).
In the following,wefirst consider independent paths, that is,the multiple paths ud by the video streams do
flows
Figure3:Validation tting for independent paths in ns:the video rver spreads the video over two paths to the client.Packet loss are caud by buffer overflows on the bottleneck links from router r k1to r k2,k=1,2.
Setting p1p2R1R2T O
1
T O
2
µ
(ms)(ms)(pkts ps) 1-10.0230.023210210 1.6 1.650
2-20.0370.036150150 1.7 1.750
3-30.0530.053200200 1.9 1.930
4-40.0340.0358080 3.0 3.380
1-20.0230.036210150 1.6 1.750
生日的祝福语1-30.0230.053210200 1.6 1.940
2-30.0360.053150200 1.7 1.940
3-40.0490.03220080 1.9 3.060
Table2:Model validation for independent paths(including both homogeneous and hetero-geneous paths)in ns.
not share a bottleneck link.We then consider correlated paths where the multiple paths share bottlenecks.
5.2Independent paths
For independent paths,we u the topology shown in Fig.3.A video rver streams a video to a client via TCP over two paths.On path k,the link(r k1,r k2)is the bottleneck link,where packets are lost due to buffer overflow,k=1,2.The link from the video rver to r k1 (and the link from r k2to the video client)has propa-gation delay of10ms and bandwidth of100Mbps.We validate our model for veral combinations of bottle-neck link configurations shown in Table1.In particular, we consider homogeneous paths where the two paths u the same configuration,and heterogeneous paths where the two paths u different configurations.
5.2.1Independent homogeneous paths
We consider4different ttings with homogeneous paths,one for each configuration of the bottleneck
link in Table1.When both paths u configuration i,we denote the tting as Setting i-i,i=1,...,4.The parameters of the video streams are averaged over30 simulation runs,as listed in Table2.The playback rate of the video is30,50or80packets per cond and each packet is1500bytes.Therefore,the bandwidth of the
