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. Geneva, 25 sep 20032/18 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. Geneva, 25 sep 20033/18 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. Geneva, 25 sep 20034/18 Testbed: simulating the Internet 1 Gbit/s switch cluster dedicated machine dedicated machine 500 streams of “background” traffic (TCP) 1 stream of aggressive protocol

5. Geneva, 25 sep 20035/18 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. Geneva, 25 sep 20036/18 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. Geneva, 25 sep 20037/18 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. Geneva, 25 sep 20038/18 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. Geneva, 25 sep 20039/18 UDT versus HighSpeed TCP Netherlight testbed 12+13 Clusternodes 200 ms RTT

10. Geneva, 25 sep 200310/18 UDT versus HighSpeed TCP Netherlight testbed 12+13 Clusternodes 200 ms RTT

11. Geneva, 25 sep 200311/18 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. Geneva, 25 sep 200312/18 UDT versus HighSpeed TCP DataTAG testbed 1+1 Clusternodes for background 110 ms RTT

13. Geneva, 25 sep 200313/18 UDT versus HighSpeed TCP DataTAG testbed 1+1 Clusternodes for background 110 ms RTT

14. Geneva, 25 sep 200314/18 RBUDP versus HighSpeed TCP [insert picture] Netherlight testbed 1+1 Clusternodes for background 200 ms RTT

15. Geneva, 25 sep 200315/18 RBUDP versus HighSpeed TCP [insert picture] DataTAG testbed 1+1 Clusternodes for background 110 ms RTT

16. Geneva, 25 sep 200316/18 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. Geneva, 25 sep 200317/18 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. Geneva, 25 sep 200318/18 Netherlight testbed (proposed) Force10 BeautyCees ONS 15454 HP 2 HP 3 VLAN A VLAN B DAS-2 Wim Chicago loopback 11a.2 11a.3 13a.4 13a.3 13a.2 13a.1 12a.3 12a.4 2.1 2.2