Characterizing Slow Start in High Speed Networks

Transcription

1 Characterizing Slow Start in High Speed Networks Kazumi Kumazoe (HMC), Masato Tsuru, Yuji Oie Kyushu Institute of Technology, Japan Mario Gerla University of California, Los Angeles, USA November 17 th, 28

2 Motivation Previous effort Goal Characterize Slow Start impact on transactional applications in high speed network scenarios. Previous slow start efforts focused on avoiding large packet losses at the Slow Start to Congestion Avoidance transaction. Conservative Slow Start Initially ramps up exponentially, as in Reno. Collects RTT information from segments sent, to measure the level of congestion. Reduces the congestion window speed of growth, once congestion build up is detected Investigate the impact of speeding up and slowing down slow start on applications performance. Motivation November 17 th, 28

3 ON/OFF ramp up Throughput Path Capacity Scenarios RTT Sender Interface Network Path Capacity Sender Interface Network Path Capacity Capacity expansion Capacity reduction November 17 th, 28

4 Quick Start with no pacing Explicit Rate/Quick Start Limited Slow Start -Path capacity -By design quick start without pacing -Congestion window adjustment Single session: -Signaling protocol inquires about a specific rate that is appropriate early in the session set up. -With pacing. - Slower than Jacobson s cwnd ramp-up November 17 th, 28

5 Application -Http transactions of 1GByte files. -Httperf for HTTP traffic generation Slow Start Experiments High Speed Transoceanic Experiments Performance Measurers -Kyushu (Japan) to Chicago and North Carolina end points 18/22msec RTT -1M, 1G, 1G interfaces -Transaction completion time -Packet losses/retransmissions November 17 th, 28

6 Three sites: Kitakyushu, Chicago, and North Carolina RTTs of 18-22msecs Transoceanic Experiments 1Mbps/ 1Gbps/ 1Gbps 1Mbps/ 1Gbps server 1 Kitakyushu Kyushu/Japan-Chicago/USA 1Mbps/ 1Gbps 1Mbps/ 1Gbps JGN2plus JGN2plus 1Gbps StarLight 1Gbps Chicago client 1 1Gbps TransPAC2 server 1 Internet2 Kyushu/Japan-North Carolina/USA 1Gbps client 1 November 17 th, 28

7 Uniform Path Capacity Scenario Kyushu-Chicago: cwnd dynamics cwnd 3.5e+7 3e+7 2.5e+7 2e+7 1.5e+7 1e+7 5e+6 RTT=18[ms], 1[Gbps]-1G[Gbps] RENO QS-app NETWORK SCENARIO 1Gbps narrowest link Short/long RTTs -KIT/Chicago : 18msecs Single flow traffic scenario Large socket buffers Httperf application sec -Capacity expansion scenario -Quick Start (no pacing) completion time is half of Reno, and one fourth of Limited Slow Start. November 17 th, 28

8 Transaction Completion Time Average Transaction Time (1M-1G) period= rate=2 rate=4 rate=8 Reno QS-app Average Transaction Time (1G-1G) period= rate=2 rate=4 rate=8 Reno QS-app NETWORK SCENARIOS 1M, 1G, 1Gbps bottleneck link Long RTTs -KIT/Chicago : 18msecs Large socket buffers Httperf application Average Transaction Time (1G-1G) -Capacity expansion scenario -Quick ramp-up shortens transaction completion time -Capacity reduction scenario -Large transaction completion time if cwnd is set too high -TCP sometimes does not recover from losses it resets for QS-app R R period= rate=2 rate=4 rate=8 Reno QS- app November 17 th, 28

9 Packet Retransmissions # of retransmitted packets (1G-1G) period= rate=2 rate=4 rate=8 Reno QS-app # of retransmitted packets (1G-1G) F F period= rate=2 rate=4 rate=8 Reno QS-app NETWORK SCENARIOS 1M, 1G, 1Gbps bottleneck link Long RTTs -KIT/Chicago : 18msecs Large socket buffers Httperf application -Capacity expansion scenario -Reno has more retransmissions, because cwnd reaches larger values (exp increase) than and QS-app. -Capacity reduction scenario -Large number of retransmissions if cwnd is set too high - has least number of retransmissions November 17 th, 28

10 Multiple Server Scenario Transaction Completion Time 4 Average Connection Time (capacity expansion - 1M-1G) 25 Average Connection Time (capacity reduction scenario) period= rate=2 RENO_flow1 RENO_flow2 _flow1 _flow2 QS-app_flow1 QS-app_flow period= rate=2 RENO_flow1 RENO_flow2 _flow1 _flow2 QS-app_flow1 QS-app_flow2 Packet Retransmission NETWORK SCENARIOS 1M, 1G, 1Gbps bottleneck link Long RTTs Flow1 first -KIT/Chicago : 18msecs Large socket buffers Httperf application -Capacity expansion scenario -Reno and perform similarly -Capacity reduction scenario -Limited Slow Start has lowest packet loss/retransmissions period= # of Retransmitted Packet (capacity reduction scenario) rate=2 November 17 th, 28 RENO_flow1 RENO_flow2 _flow1 _flow2 QS-app_flow1 QS-app_flow2

11 Kyushu-North Carolina: cwnd dynamics Favorable Path Capacity Scenario bytes 3.5e+7 3e+7 2.5e+7 2e+7 1.5e+7 1e+7 5e+6 cwnd, RTT=223[ms], 1[Gbps]-1[Gbps] sec reno lss qs qs_app 3.5e+7 3e+7 2.5e+7 cwnd, RTT=223[ms], 1[Gbps]-1[Gbps] reno lss qs qs_app 1Gbps/ 1Mbps 1Gbps/ 1Mbps Kitakyushu JGN2plus 1Gbps TransPAC2 NCSU Internet2 1Gbps client 1 NETWORK SCENARIO 1Gbps narrower link Short/long RTTs -KIT/NCSU : 22msecs Single flow traffic scenario Large socket buffers Httperf application 2e+7 1.5e+7 1e+7 5e Capacity expansion scenario -Quick Start and have largest transaction completion time bytes sec November 17 th, 28

12 Transaction Completion Time Average Connection Time (1M-1G) period= rate=2 rate=4 rate=8 RENO QS_APP QS Average Connection Time (1G-1G) period= rate=2 rate=4 rate=8 RENO QS_APP QS -Capacity expansion scenario -All SSs have similar transaction completion times -Capacity reduction scenario -QS-app has largest transaction completion times sometimes resets TCP session Average Connection Time (1G-1M) R R R RENO QS_APP QS NETWORK SCENARIOS 1M, 1G, bottleneck link Long RTTs -KIT/NCSU : 22msecs Large socket buffers Httperf application period= rate=2 rate=4 rate=8 November 17 th, 28

13 Packet Retransmissions # of retransmited packet (1G-1G) period= rate=2 rate=4 rate=8 RENO QS_APP QS # of retransmitted packets (1G-1M) F F F period= rate=2 rate=4 rate=8 RENO QS_APP QS 1Gbps/ 1Mbps 1Gbps/ 1Mbps Kitakyushu JGN2plus 1Gbps TransPAC2 NCSU Internet2 1Gbps client 1 NETWORK SCENARIOS 1M, 1Gbps bottleneck link Long RTTs -KIT/NCSU : 22msecs Large socket buffers Httperf application -Capacity expansion scenario -QS has largest number of retransmissions - has increasing number of retransmissions with simultaneous sessions -Capacity reduction scenario -QS-app has largest retransmissions -QS with pacing still sustain large retransmissions, as compared with Reno and November 17 th, 28

14 Slow Start Impact on Applications Remarks Slow Start - - Back-to-back packet transmission may cause large packet loss, with subsequent adverse impact on application performance. -High server network interface speed may increase transaction completion time. -For underutilized path capacity expansion scenarios, it is irrelevant how quickly cwnd ramp up is performed. -Speeding up Slow Start may cause resets, if there is no pacing. -Slowing down Slow Start may cause poor application performance. -For all Slow Start mechanisms, there are favorable and unfavorable network scenarios -Dynamic detection of network and path scenarios November 17 th, 28

15 Collaborators Kazumi Kumazoe HMC/KIT Tsuru Masato KIT Yuji Oie - KIT Mario Gerla UCLA Thank you! References [Kumazoe9] K. Kumazoe, M. Gerla, D. Cavendish, M. Tsuru, Y. Oie, Improving Performance of the transactional Internet, Submitted for publication 28. November 17 th, 28