Yin Xu, Wai Kay Leong, Ali Razeen Ben Leong Duke University - PowerPoint PPT Presentation

Yin Xu, Wai Kay Leong, Ali Razeen Ben Leong Duke University National University of Singapore 1

 US smartphone penetration exceeded 50% in Q2, 2012  Mobile data traffic growing rapidly as well Source: http://www.chetansharma.com/USmarketupdateQ22012.htm 2

 Users uploading significant amounts of data in the form of photos and videos e.g. AT&T observed 40% more data uploaded than downloaded during a football match (7 Feb 2012)  Uploads often conducted in the background 3

Hmm…Upload Hmm…Show Hmm…I still Hmm… I got !!Stupid phone!! Hmm…I got …Facebook… ah!! I cannot all my photo to off my new 25GB extra refresh my have 10GB Stupid network!! the new HTC …blabla…. facebook wall! DropBox!!! phone!! DropBox of data….lolo one X…lala ….....I should complain!! space!! What happened? 4

Background uploads can degrade downloads significantly! 5

 Android Phones  3 Local Telcos  7.2 Mbps downlink  2.0 Mbps uplink Server Download 1MB Download 1MB without upload Upload until download Client Upload 1MB completion

With Upload (s) Without Upload (s) 7

With Upload (kbps) Without Upload (kbps) 8

Download Performance Uplink Bandwidth (kbps) 9

Download 1MB Server Continuous background upload Client

Delay (s) Packet arrival time (s) 11

 NOT caused by ACK Compression  Data Pendulum Problem [Heusse et al. 2011]  Sized properly, buffers take turns to fill up  Sized improperly, low-speed link with large buffer becomes the sole bottleneck  Uplink is the bottleneck in a 3G/HSPA mobile network 12

13

Upload Throughput (kbps) NOPE! CANNOT USE A FIXED SIZE BUFFER! Time of Day (24 hours) 14

 Optimizing how the ACKs are sent [Balakrishnan et al. 1999/2002]  Using different queues for data and ACK packets [Podlesny et al. 2012]  TCP Vegas [Brakmo et al. 1995] All Sender-Side Solutions 15

 Not General  Only works for the devices already deployed with the solution  Devices may use network interfaces other than 3G/HSPA (e.g. Wi-Fi)  “Implement complexity at the server, not the client”  It may take years to update client-side software [Adya et al. 2011] 16

Receiver-Side Flow Control (RSFC) 17

Our Our Appr Approa oach  Can implement at ISP network proxies  Works transparently for any device using the 3G/HSPA mobile network  Changes immediately deployable

Easily deployed at ISP proxy Base station A go A good d Proxy pl plac ace f for Internet RS RSFC FC 19

 Freeze-TCP [Goff et al. 2000]  Reducing delay for interactive applications while maintaining throughput for bulk transfers [Spring et al. 2000]  Improving fairness [Kalampoukas et al. 2002, Andrew et al. 2008] Used for Other Purposes 20

Reduce # of packets in the uplink buffer by adjusting the TCP receiver window ( rwnd ) What is the right rwnd ? 21

rwnd Value ue  Set to bandwidth-delay product (BDP)?  Not so simple…  How do we estimate BDP?  Network fluctuations

Appr Approa oach: Ne : Nega gativ ive Feedba dback  Esti Estima mate ti time me pack packet spends i spe in b buffer t buff usin ing TCP Ti CP Time mest stamp  Se Set a thre t a threshold shold T  t buff > T, clamp rwnd  t buff < T, increase rwnd

Estimating t bu buff Receiver Packets in buffer Sender Timestamp: Time x TSval = t s t s x t buff x t r – t s = RD Relative Delay x x t u time = t r 24

Estimating t bu buff Receiver Packets in buffer Sender Timestamp: Time x x TSval = t s t s t u time = t r t r – t s = RD min Minimal Relative Delay t buff = RD – RD min No need to synchronize sender and receiver! 25

 Measure receive rate ρ at receiver  Minimal RTT ( RTT min )  Ideal window is the bandwidth-delay product:  rwnd = ρ × RTT min 26

 t buff > T, rwnd = ρ × RTT min (fast state)  t buff < T, rwnd++ (slow state)  In our implementation  T is set to RTT min 27

 Changes in bandwidth  Decrease in the delay  Increase in the delay ?  Slight increase: detect increased receive rate ρ  Large increase: monitor state See details in paper! 28

 Reduces RTT  Improves download throughput  Reduces webpage loading time  Fair and efficient  Adapts to changes in network conditions  Compatible with sender-side algorithms 29

 Reduces RTT  Improves download throughput  Reduces webpage loading time  Fair and efficient  Adapts to changes in network conditions  Compatible with sender-side algorithms 30

Server Upload Upload 1MB with 1MB with Client RSFC Cubic

32

33

35

Download 1MB (d2) Download 1MB (d1) Server Download (d0) 1MB without upload Upload (u1)with Cubic Upload (u2)with RSFC Client until download until download completes completes

37

38

39

41

 Alexa top 100 sites Web surfing Web surfing Web surfing without upload Client Server Upload with Cubic Upload with RSFC until website is until website is loaded loaded

43

44

45

Con Concl clusion ion  Saturated uplink can cause serious performance degradation  Receiver-Side Flow Control  Reduces queuing delay significantly  Improves downstream performance  Reduces loading time of webpages  Compatible with existing TCP variants  Easily deployed at ISP proxies

47

 Run two RSFC uploads concurrently  Calculate Jain fairness index: + + 2 2 2 ( ) /( 2 ( )) R R R R 1 2 1 2 48

49

 Run two RSFC uploads concurrently  Compare the aggregate throughput to a single TCP: 1 + ( ) / R R R 2 tcp 50

51

52

 Compare with one RSFC version without:  Checking ρ  Monitor state 53

Without the two methods Delay increase cannot be detected. Inefficient! 54

With the two methods Delay increase can be detected. Efficient! 55