Slides - University of Michigan

Download Report

Transcript Slides - University of Michigan

Junxian Huang 1 Yihua Guo 1 Z. Morley Mao 1 Yuanyuan Zhou Subhabrata Sen 1 University of Michigan Feng Qian 2 1 2 Qiang Xu 1 Oliver Spatscheck 2 AT&T Labs - Research 2

August 15, 2013

  ◦ 4G LTE (Long Term Evolution) is future 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

   How network resources are utilized 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

 Data collection and data set  Abnormal TCP behavior  Bandwidth estimation  Inefficient Resource Usage of Applications  Conclusion 4

5

6

  ◦ ◦ ◦ 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 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 collection and data set  Abnormal TCP behavior  Bandwidth estimation  Inefficient Resource Usage of Applications  Conclusion 8

 Large buffers in the LTE networks may cause high queuing delays 1 0.8

0.6

0.4

0.2

0 0 200 400 600 800 1000 1200 Bytes in flight (KB) Bytes in flight – unacknowledged TCP bytes 9

600 500 400 300 200 100 0 0 LTE Carrier A 100 200 300 400 500 600 Bytes in flight (KB) 350 300 250 200 150 100 50 0 0 LTE Carrier B 100 200 300 400 500 600 Bytes in Flight (KB) 10

3e+06 2.5e+06 2e+06 1.5e+06 1e+06 500000 0 0 0.5

Data ACK 1 1.5

2 Time (second) 2.5

3 11

3e+06 2.5e+06 2e+06 1.5e+06 1e+06 500000 0 0 bytes in flight growing 0.5

1 1.5

Data ACK 2 Time (second) 2.5

3 12

3e+06 2.5e+06 2e+06 1.5e+06 1e+06 500000 0 0 0.5

Packet loss Data ACK 1 1.5

2 Time (second) 2.5

3 13

Fast retransmission allows TCP to directly send the lost segment to the receiver possibly preventing retransmission timeout 3e+06 2.5e+06 2e+06 1.5e+06 1e+06 500000 0 0 0.5

Fast retransmission 1 1.5

Data ACK 2 Time (second) 2.5

3 14

TCP uses RTT estimate to update retransmission timeout (RTO) However, TCP does not update RTO based on duplicate ACKs 3e+06

RTO

»

RTT

+ 4

RTTVAR

2.5e+06 2e+06 RTT: 262ms RTO: 290ms 1.5e+06 1e+06 500000 0 0 0.5

Duplicate ACKs Data ACK 1 1.5

2 Time (second) 2.5

3 15

Retransmission timeout causes slow start 3e+06 2.5e+06 2e+06 1.5e+06 1e+06 500000 0 0 RTT: 356ms RTO: 290ms RTT > RTO, timeout!

0.5

1 Slow start 1.5

Data ACK 2 Time (second) 2.5

3 16

   ◦ 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 undesired slow start SACK enabled in 82.3% of all duplicate ACKs 17

 Data collection and data set  Abnormal TCP behavior  Bandwidth estimation  Inefficient Resource Usage of Applications  Conclusion 18

   Goal: understanding the network utilization efficiency of mobile 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

Typical TCP data transfer 20

S: packet size Sending rate between t 0 and t 4 is 21

From UE’s perspective, the receiving rate for these n − 2 packets is 22

Typically, t 2 to t 1 t 5 and t 6 is very close and similarly for 23

t Use the TCP Timestamp option to calculate 6 − t 2 (G is a measurable constant) 93% of TCP flows have the TCP Timestamp option enabled 24

    Compute a list of {(R snd window along the flow , R rcv )} by sliding a ◦ {R rcv } is the estimated bandwidth Some restrictions of R snd applies (details in paper) Estimation error < 8% based on local exprs Estimated the available bandwidth for over 90% of the large (> 1MB) downlink flows 25

   ◦ ◦ ◦ 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 Inefficient TCP behaviors 26

LTE network has highly varying available bandwidth 1 0.8

BW estimation for sample flow 1 BW estimation for sample flow 2 0.6

0.4

0.2

0 0 50 100 150 Time (s) 200 250 300 27

    Under small RTTs, TCP can utilize over 95% of the varying available bandwidth When RTT exceeds 400∼600ms, the utilization 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

 Data collection and data set  Abnormal TCP behavior  Bandwidth estimation  Inefficient Resource Usage of Applications  Conclusion 29

 ◦ Shazam (iOS app) downloading 1MB audio file Ideal download time 2.5s

v.s. actual 9s 1.2e+06 1e+06 800000 600000 400000 200000 0 0 5 TCP receive window full Data Ideal case ACK 10 15 20 Time (second) 25 30 30

   53% of all downlink TCP flows experience full receive window 91% of the receive window bottlenecks happen in the initial 10% of the flow duration Recommendation: reading downloaded data from TCP’s receiver buffer quickly 31

 ◦ Netflix (iOS app) periodically video chucks every 10s requests for Keeping UE radio interface always at the high power state, incurring high energy overheads 55120 55100 55080 55060 55040 0 HTTP Request HTTP Response Aggregate throughput 50 100 150 Time (second) 200 30 25 20 15 10 5 0 32

 Data collection and data set  Abnormal TCP behavior  Bandwidth estimation  Inefficient Resource Usage of Applications  Conclusion 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

35