1 / 18

TCP friendlyness: Progress report for task 3.1

TCP friendlyness: Progress report for task 3.1. Freek Dijkstra Antony Antony, Hans Blom, Cees de Laat University of Amsterdam. CERN, Geneva. 25 September 2003. What is TCP friendly?.

starr
Download Presentation

TCP friendlyness: Progress report for task 3.1

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. TCP friendlyness:Progress report for task 3.1 Freek Dijkstra Antony Antony, Hans Blom, Cees de Laat University of Amsterdam CERN, Geneva 25 September 2003

  2. What is TCP friendly? The term “TCP-friendly” or "TCP-compatible" means that a flow that behaves under congestion like a flow produced by a conformant TCP. -- Survey of Protocols and Mechanisms for Enhanced Transport over Long Fat Pipes, Eric He et. al. • Inter-protocol fairness versus Intra-protocol fairness

  3. Protocols other then TCP • RBUDP (Reliable Blast UDP) • SABUL (Simple Available Bandwith Utilization Library) / UDT • Tsunami (file-to-file) • HighSpeed TCP • Scalable TCP • FAST TCP • And: SCTP, DCCP, RUDP, RAPID, ROCKS, Atou, XCP (Explicit Congestion control Protocol), CADPC / PTP Reference: UDP, TCP

  4. Testbed: simulating the Internet 500 streams of “background” traffic (TCP) cluster cluster switch switch 1 Gbit/s dedicated machine dedicated machine 1 stream of aggressive protocol

  5. Testbed progress • Testbeds used: DataTAG, Netherlight/StarLight • Problems getting a reliable testbed: • DataTAG testbed has limited number of clusternodes, so only useful for HighSpeed TCP as background, not for plain TCP • Possible packet loss between two switches in NetherLight testbed

  6. Measurement progress • Preliminary SABUL and UDT tests done. • RBUDP measured, but only on SARA hosts. • TCP & Highspeed TCP (baseline measurement) not yet performed due to testbed difficulties. • Tsunami is disk-to-disk instead of memory-to-memory. Suffers from synchronization problems as well.

  7. Software Adjustments • For RBUDP, UDT and SABUL, Jason Lee and Hans Blom created a Iperf-like interface with client-server programs. • For our tools, the client is the sender, and the server is the receiver. The above distributions use the opposite terminology. • Our tools optionally implement time-limits and interval reports. • Adjusted Iperf to allow shaped TCP traffic.

  8. SABUL / UDT • Created by Yunhong Gu and Robert Grossman (LAC, University of Illinois at Chicago) • http://sourceforge.net/projects/dataspace/ • Authors claim both intra-protocol fairness (it uses AIMD-like congestion control mechanism), as well as inter-protocol fairness.

  9. UDT versus HighSpeed TCP Netherlight testbed 12+13 Clusternodes 200 ms RTT

  10. UDT versus HighSpeed TCP Netherlight testbed 12+13 Clusternodes 200 ms RTT

  11. Netherlight UDT Observations • The adjustment of the UDT flow at the moment of the starting TCP flows is independent for the # of TCP flows N for N >= 312 • When the # of TCP flows N is N <= 468, the bandwidth of the UDT flow increases again after the TCP flows are started. • The maximum achieved TCP bandwidth, after the UDT flow ended, could be found for a #  TCP flows of N = 312 and a shaped bandwidth of S = 3 Mbits/s. The bandwidth of the combined UDT  + TCP flow is also largest for the same configuration.

  12. UDT versus HighSpeed TCP DataTAG testbed 1+1 Clusternodes for background 110 ms RTT

  13. UDT versus HighSpeed TCP DataTAG testbed 1+1 Clusternodes for background 110 ms RTT

  14. RBUDP versus HighSpeed TCP Netherlight testbed 1+1 Clusternodes for background 200 ms RTT [insert picture]

  15. RBUDP versus HighSpeed TCP DataTAG testbed 1+1 Clusternodes for background 110 ms RTT [insert picture]

  16. Questions • Is influence of number of background flows important? Is this due to bandwidth or due to number of flows? • Is delay an important factor? Is it delay or bandwidth-delay product? • What metrics to use to verify claims of inter-protocol fairness?

  17. Parameters variation • Transport protocols and mechanisms • Number of background flows • Bandwidth per background flow • Flow window for alternate protocols (UDT only) • Use TCP or HighSpeed TCP as background traffic (we need enough clusternodes available on testbed) • Delay (depends on available testbeds) • Total bandwidth (depends on available testbeds)

  18. Wim Netherlight testbed (proposed) HP 2 DAS-2 Force10 VLAN A ONS 15454 11a.2 BeautyCees Chicago loopback 13a.1 13a.2 12a.3 2.1 13a.3 12a.4 2.2 VLAN B 13a.4 11a.3 HP 3

More Related