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?
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
Geneva, 25 sep 2003
2/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
Geneva, 25 sep 2003
3/18
Testbed: simulating the Internet
cluster
500 streams of
“background” traffic (TCP)
switch
cluster
switch
1 Gbit/s
dedicated
machine
Geneva, 25 sep 2003
1 stream of aggressive protocol
dedicated
machine
4/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
Geneva, 25 sep 2003
5/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 memoryto-memory. Suffers from synchronization
problems as well.
Geneva, 25 sep 2003
6/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.
Geneva, 25 sep 2003
7/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.
Geneva, 25 sep 2003
8/18
UDT versus HighSpeed TCP
Netherlight
testbed
12+13
Clusternodes
200 ms RTT
Geneva, 25 sep 2003
9/18
UDT versus HighSpeed TCP
Netherlight
testbed
12+13
Clusternodes
200 ms RTT
Geneva, 25 sep 2003
10/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.
Geneva, 25 sep 2003
11/18
UDT versus HighSpeed TCP
DataTAG
testbed
1+1
Clusternodes
for background
110 ms RTT
Geneva, 25 sep 2003
12/18
UDT versus HighSpeed TCP
DataTAG
testbed
1+1
Clusternodes
for background
110 ms RTT
Geneva, 25 sep 2003
13/18
RBUDP versus HighSpeed TCP
Netherlight
testbed
[insert picture]
1+1
Clusternodes
for background
200 ms RTT
Geneva, 25 sep 2003
14/18
RBUDP versus HighSpeed TCP
DataTAG
testbed
[insert picture]
1+1
Clusternodes
for background
110 ms RTT
Geneva, 25 sep 2003
15/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?
Geneva, 25 sep 2003
16/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)
Geneva, 25 sep 2003
17/18
Netherlight testbed (proposed)
HP 2
DAS-2
Force10
11a.2
VLAN A
BeautyCees
ONS
15454
Chicago
loopback
13a.1
13a.2
12a.3
2.1
13a.3
12a.4
2.2
Wim
13a.4
VLAN B
11a.3
HP 3
Geneva, 25 sep 2003
18/18