1 / 20

Characterization of TCP flows over Large-Fat Networks

Characterization of TCP flows over Large-Fat Networks. Antony Antony, Johan Blom, Cees de Laat, Jason Lee, Wim Sjouw University of Amsterdam 03/02/2003. SW. SW. PC. PC. OC 12, 622Mbps. OC 48, 2.5Gbps. SURFnet Amsterdam Chicacgo 96msec, 2001 - 2002. R. R. PC. PC. OC 192, 10 Gbps.

bernard-ellison
Download Presentation

Characterization of TCP flows over Large-Fat Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Characterization of TCP flows over Large-Fat Networks Antony Antony, Johan Blom, Cees de Laat, Jason Lee, Wim Sjouw University of Amsterdam 03/02/2003

  2. SW SW PC PC OC 12, 622Mbps OC 48, 2.5Gbps SURFnet Amsterdam Chicacgo 96msec, 2001 - 2002 R R PC PC OC 192, 10 Gbps SURFnet Amsterdam Chicacgo 96msec, iGrid 2002 SW R R SW PC PC 2.4 Gbps DataTag CERN Chicacgo 110 msec, 2002, till now Networks used

  3. Layer - 2 requirements from 3/4 WS L2 fast->slow L2 slow->fast WS fast slow fast high RTT TCP is bursty due to sliding window protocol and slow start algorithm. Window = BandWidth * RTT & BW == slow fast - slow Memory-at-bottleneck = ----------- * slow * RTT fast

  4. (19 of 24) 5000 1 kByte UDP packets

  5. (20 of 25) Self-clocking of TCP high RTT WS L2 fast->slow L2 slow->fast WS fast fast 14 µsec 20 µsec 20 µsec 20 µsec 20 µsec

  6. Forbidden area, solutions for s when f = 1 Gb/s, M = 0.5 Mbyte AND NOT USING FLOWCONTROL Possible BW due to lack of buffer at the bottleneck s 158 ms = RTT Amsterdam - Vancouver OC12 OC9 OC6 OC3 OC1 rtt

  7. Characterising a TCP Flow • Three different phases of TCP • Bandwidth discovery phase • Steady state • Congestion avoidance • Is it due to Implementations, Protocol or Philosophical ?

  8. Receiver can’t cope with burst

  9. TCP Flow fall off from slow start without packet a loss

  10. Modifications • Faster Host/NIC • Pacing out Packets at device level. • HSTCP, using Net100 2.1 • Q length on the Interface (Linux Specific) • IFQ manipulation using Net100 • Changing TXQ using ifconfig

  11. Adding Delay at Device level

  12. NIKHEF -> EVL 618Mbps, 3min

  13. NIKHEF -> ANL 410Mbps, ~Hour over a 622Mbps Path

  14. Throughput vs TXQ Amsterdam to Chicago (Linux) Linux Default (100)

  15. TCP performance comparison.

  16. Near GigE using vanilla TCP! Sunnyvale – Chicago – Amsterdam – CERN – Amsterdam 196 msec Path • 980Mbps Sunnyvale to Amsterdam (196 msec) Jumbo Frames, no congestion, entire path was OC192 • Throughput drops when there is congestion • With HSTCP (Net100) flow recovers from congestion events

  17. Ideal Flow (196 msec, 980Mbps)(Jumbo Frames)

  18. Conclusion • Throughput of a TCP flow depend on Slow Start Behavior • If you get early congestion, your flow will probably not recover before you finish • TCP is not robust. • Is this an Implementation , Protocol or Philosophical problem ?

  19. Future Work • Higher speed single TCP flows in the WAN • Using 10Gig NICs on the end hosts • Use traces captured from wire to examine behavior of TCP. • Closer look at TCP behavior over Lambdas vs. routed networks.

  20. Thanks! URL http://www.science.uva.nl/research/air/

More Related