High-performance bulk data transfers with TCP.ppt

1、High-performance bulk data transfers with TCP,Matei Ripeanu University of Chicago,Problem,Bulk transfers transfer of many large blocks of data from one storage resource to another delivery order is not important Parallel flows to accommodate to parallel end systems Questions What is the achievable t

2、hroughput using TCP Which TCP extensions are worth investigating Do we need another protocol?,Outline,TCP review Parallel transfers with TCP shared environments non-shared environments Considering alternatives to TCP Conclusion and future work,TCP Review,Provides a reliable, full duplex, and streami

3、ng channel Design assumptions: Low physical link error rates assumed Packet loss = congestion signal No packet reordering at network (IP) level Packet reordering = congestion signal Design assumptions challenged today! Parallel networking hardware = reordering Dedicated links, reservations = no cong

4、estion Bulk transfers = streaming not needed,TCP algorithms,Flow control ACK clocked Slow start exponential growth Congestion Control set sstresh to cwnd/2, slow start until sstresh then linear growth Fast Retransmit Fast Recovery,Steady state throughput model,M. Mathis,Steady state throughput model

5、,Parallel TCP transfers - - shared environments,Advantages: More resilient to network layer packet losses More aggressive behavior: faster slow start and recovery Drawbacks: Aggregated flow not TCP friendly! Does not respond to congestion signals (RED routers might take “appropriate” action) Solutio

6、n: E-TCP (RFC2140) Difficult to configure transfer properly to maximize link utilization,Shared environments (cont),Framework for simulation studies Change network path proprieties, no. of lows, loss/reordering rates, competing traffic etc. Identify additional problems: TCP congestion control does n

7、ot scale Unfair sharing of the available bandwidth among flows Low link utilization efficiency If competing traffic is formed by many short lived flows, performance is even worse Self synchronizing traffic Burstiness,50 flows try to send data over paths that has a 1 Mbps bottleneck segment. RTT=80ms

8、 and MSS=1000bytes. Router buffers: 100 packets. The graph reports the number of packets successfully sent during a 600s period.,Fair share.,Non-shared environments,Dedicated links or reservations Transfer can be set up properly: Use TCP tools to discover: bottleneck bandwidth, MSS, RTT; pipe size P

9、S = bw*RTT/MSS Set receivers advertised window: rwnd=PS/no_flows No packets will be lost due to buffer overflow TCP design assumptions do not hold anymore Packet loss Reordering,Non-shared environment,Analytical models supported by simulations: Throughput as a function of: Network path proprieties:

10、RTT, MSS, bottleneck bandwidth Number of parallel flows used Frequency of packet loss/reordering events. (On optical links link error rate is very low) Achievable throughput using TCP can get close to 100% of bottleneck bandwidth,Single flow throughput as a function of loss indication rates. MSS = 5

11、00bytes Bottleneck bandwidth=100Mbps; RTT=100ms;.,Increasing segment size: to 1460, 4400 and 9000 bytes Single flow throughput as a function of loss indication rates for various pipe sizes for various segment sizes. Bottleneck bandwidth=100Mbps; RTT=100m.,Increase the number of parallel flows. The n

12、ew transfer uses 5 flows. Bottleneck bandwidth=100Mbps; RTT=100ms;.,To increase throughput,Decrease pipe size for each flow: segment size (hardware trend) number of parallel flows Detect packet reordering events; SACK (RFC2018; RFC2883) could be used to pass info adjust duplicate ACK threshold dynam

13、ically “undo” reduction of the congestion window Skip slow start; cache and share RTT values among flows (T/TCP, ),Alternatives,A rate-based protocol like NETBLT (RFC998) Shared environments Aggarwal & all 00 simulation studies Counterintuitive: no performance improvements Non-shared environments Th

14、eoretically should be a bit faster, but needs to beat the huge amount of engineering around TCP implementations Requires smaller buffers at routers Simulation studies needed,Summary and next steps,We have a framework for simulation studies of high-performance transfers. Used it for investigating TCP performance in shared and non-shared environments.Next: Use simulations to evaluate SACK TCP extensions effectiveness in detecting reordering. Evaluate decisions after reordering is detected. Simulate a rate-based protocol and compare with TCP dialects,