An In-depth Study of LTE- Effect of Network Protocol and .ppt

1、An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance,Junxian Huang1 Feng Qian2 Yihua Guo1 Yuanyuan Zhou1 Qiang Xu1 Z. Morley Mao1 Subhabrata Sen2 Oliver Spatscheck2 1University of Michigan 2AT&T Labs - Research,August 15, 2013,4G LTE (Long Term Evolution) is f

2、uture trend Initiated by 3GPP in 2004 Entered commercial markets in 2009 Now available in more than 10 countries LTE uses unique backhaul and radio network technologies Much higher available bandwidth and lower RTT, compared with 3G,2,LTE is New, Requires Exploration,How network resources are utiliz

3、ed across different protocol layers for real users? Are increased bandwidth efficiently utilized by mobile apps and network protocols? Are inefficiencies in 3G networks still prevalent in LTE?,3,LTE not extensively studied in commercial networks,Data collection and data setAbnormal TCP behaviorBandw

4、idth estimationInefficient Resource Usage of ApplicationsConclusion,4,5,LTE Network Topology of the Studied Carrier,6,LTE Network Topology of the Studied Carrier,Data set statistics From 22 eNodeB at a U.S. metropolitan area Over 300,000 users 3.8 billion packets, 3 TB of LTE traffic Collected over

5、10 consecutive days Data contents: packet header trace IP and transport-layer headers 64-bit timestamp No payload data is captured except for HTTP headers,7,Data Set,Data collection and data setAbnormal TCP behaviorBandwidth estimationInefficient Resource Usage of ApplicationsConclusion,8,Large buff

6、ers in the LTE networks may cause high queuing delays,9,Queueing Delay,Bytes in flight unacknowledged TCP bytes,10,Similar Observations in Controlled Experiments,LTE Carrier A,LTE Carrier B,11,High Queueing Delay Causes Unexpected TCP Behavior,12,High Queueing Delay Causes Unexpected TCP Behavior,by

7、tes in flight growing,13,High Queueing Delay Causes Unexpected TCP Behavior,Packet loss,14,High Queueing Delay Causes Unexpected TCP Behavior,Fast retransmission,Fast retransmission allows TCP to directly send the lost segment to the receiver possibly preventing retransmission timeout,15,High Queuei

8、ng Delay Causes Unexpected TCP Behavior,RTT: 262ms RTO: 290ms,TCP uses RTT estimate to update retransmission timeout (RTO) However, TCP does not update RTO based on duplicate ACKs,Duplicate ACKs,16,High Queueing Delay Causes Undesired Slow Start,RTT: 356ms RTO: 290ms RTT RTO, timeout!,Retransmission

9、 timeout causes slow start,Slow start,For all large TCP flows (1 MB) 61% have at least one packet loss Within them, 20% have undesired slow start. Example: a 3-minute flow 50 undesired slow starts Average throughput of only 2.8Mbps The available bandwidth 10Mbps TCP SACK can be used to mitigate unde

10、sired slow start SACK enabled in 82.3% of all duplicate ACKs,17,Prevalence of the Undesired Slow-start Problem,Data collection and data setAbnormal TCP behaviorBandwidth estimationInefficient Resource Usage of ApplicationsConclusion,18,Goal: understanding the network utilization efficiency of mobile

11、 applications Active probing is not representative High-level approach: identify short periods during which the sending rate exceeds the wireless link capacity and measure the receiving rate to infer the bandwidth,19,Bandwidth Estimation From Passive Traces,20,Bandwidth Estimation Algorithm,Typical

12、TCP data transfer,21,Bandwidth Estimation Algorithm,S: packet size Sending rate between t0 and t4 is,22,Bandwidth Estimation Algorithm,From UEs perspective, the receiving rate for these n 2 packets is,23,Bandwidth Estimation Algorithm,Typically, t2 is very close to t1 and similarly for t5 and t6,24,

13、Bandwidth Estimation Algorithm,Use the TCP Timestamp option to calculate t6 t2 (G is a measurable constant),93% of TCP flows have the TCP Timestamp option enabled,Compute a list of (Rsnd , Rrcv ) by sliding a window along the flow Rrcv is the estimated bandwidth Some restrictions of Rsnd applies (de

14、tails in paper) Estimation error 1MB) downlink flows,25,Bandwidth Estimation Algorithm,Overall low bandwidth utilization Median: 20% Average: 35% For 71% of the large flows, the bandwidth utilization ratio is below 50% Reasons for underutilization Small object size Insufficient receiver buffer Ineff

15、icient TCP behaviors,26,Bandwidth Utilization by Real Applications in LTE,27,Bandwidth Estimation Timeline for Two Sample Large TCP Flows,LTE network has highly varying available bandwidth,Under small RTTs, TCP can utilize over 95% of the varying available bandwidth When RTT exceeds 400600ms, the ut

16、ilization ratio drops to below 50% For the same RTT, higher variation leads to lower utilization Long RTTs can degrade TCP performance in the LTE networks,28,LTE Bandwidth Variability, RTT and TCP Performance,Data collection and data setAbnormal TCP behaviorBandwidth estimationInefficient Resource U

17、sage of ApplicationsConclusion,29,30,Inefficient Resource Usage Limited TCP Receive Window,Shazam (iOS app) downloading 1MB audio file Ideal download time 2.5s v.s. actual 9s,TCP receive window full,53% of all downlink TCP flows experience full receive window 91% of the receive window bottlenecks ha

18、ppen in the initial 10% of the flow duration Recommendation: reading downloaded data from TCPs receiver buffer quickly,31,Inefficient Resource Usage Limited TCP Receive Window,Netflix (iOS app) periodically requests for video chucks every 10s Keeping UE radio interface always at the high-power state

19、, incurring high energy overheads,32,Inefficient Resource Usage Application Design,Data collection and data setAbnormal TCP behaviorBandwidth estimationInefficient Resource Usage of ApplicationsConclusion,33,Performance inefficiencies in LTE Undesired slow starts observed in 12% of large TCP flows 53% of downlink TCP flows experience full TCP receive window Cross-layer improvements needed at diff. layers At TCP (e.g. updating RTT estimations based on dup ACK) At app design (e.g. maintaining application-layer buffer to prevent TCP receive window becoming full),34,Conclusions,35,Thank you!,