ExtremeTCP tanıtım

1. 2012
eXtreme TCP
Performance
Testing Guide
eXtreme TCP: applicability scope,
Intercontinental global tests and
local download tests
EXtreme TCP (XTCP) is a technology that dramatically improves
network performance by maximizing network bandwidth utilization.
Provided below are some tests that attempt to cover the scope of
applicability of XTCP and show its performance in comparison with
standard TCP.
10.06.2012

2. Foreword
Thank you for your interest in eXtreme TCP (XTCP). EXtreme TCP is a new technology developed by
Mainline Net Holdings, Ltd. which dramatically improves networking performance by allowing
the transport protocol to better utilize all available networking resources under various
conditions. EXtreme TCP can be used everywhere standard TCP is used.
This document shows the results of multiple tests of the performance of XTCP as compared with
standard TCP and provides some simple instructions as to how you can test XTCP yourself.
The Automated Windows Tests…………………………………………………………..…………………………2
The Automated Linux tests…………………………………………………………………….……………………16
2

3. 1. Automated Windows tests
The tests were performed by transferring a 64 MB file via FTP. Tests were performed for
different sender and recipient destinations around the world. The tests were performed on
the Internet under real world conditions. Other than sending the 64 MB file, nothing was
done to influence or control traffic between the sender and the recipient.
Download rates during the transfer were recorded in bytes per second and graphed against
time. The yellow graph represents standard TCP transfer rates; the green graph represents
XTCP transfer rates. Note that the performance graphs are defined only while the 64 MB file
is being downloaded. Thus, if one graph ends before the other, this signifies that one system
(usually XTCP) was able to download the entire file before the other.1
Section 1 tests were invoked to compare XTCP performance against standard MS Windows
TCP implementation. Servers involved in this testing run MS Windows Server 2003 or MS
Windows Server 2008 OS.
1 To better simulate real world conditions the TCP and XTCP transfers were performed consecutively and not
simultaneously. One would not ordinarily perform both an XTCP and TCP transfer at the same time by the same
computer. Since temporal variations of bandwidth/latency are essentially random, the consecutive operation does not
cause any lack of fairness. Furthermore multiple tries confirmed that the tests results provided below are not
aberrations.
3

4. 1.1. From the United Kingdom to New-York, USA.
Notes: This shows the normal or usually expected flow of transmission. XTCP detected
channel capacity due to packet loss during initial exponential growth of send window. TCP
was not able to transmit anywhere close to channel capacity, because standard TCP limits
transmission rates for particular channel latencies In this example, XTCP transmitted the file
in around a tenth of the time required for TCP. The non-saturated channel latency for this
chnel was 75 ms.
4

5. 1.2. From the United Kingdom to Central America.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity
due to sufficient latency growth during network saturation. This allowed XTCP to finish in
less than half the time of TCP. Non-saturated channel latency: 121 ms.
5

6. 1.3. From the United Kingdom to California, USA.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity to packet
loss during initial exponential growth of send window. This allowed XTCP to finish in less than
twelfth the time of TCP. Non-saturated channel latency: 141 ms.
6

7. 1.4. From New-York, USA to the United Kingdom.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. This allowed XTCP to finish in around a tenth
the time of TCP. Non-saturated channel latency: 75 ms.
7

8. 1.5. From New-York, USA to Central America.
Notes: This is probably an example of the worst case scenario in terms of XTCP benefits over TCP.
This environment is rather advantageous for TCP, because the latencies are relatively low. Low
latencies allow TCP to better utilize the available bandwidth. Furthermore, the connection is rather
stable, i.e., it lacks sharp variations of available bandwidth and random dropped packets which tend
to create severe slowdowns for TCP. Indeed here TCP is not stuck transmitting at a fraction of the
available bandwidth, as was the case for most other examples.
Nevertheless, even in this advantageous-for-TCP environment, XTCP manages to beat TCP by about
8%. This happens because the more responsive XTCP algorithm is able to more accurately lock onto
the available bandwidth. TCP, on the other hand, still features varying rates of transmission with
frequent slowdowns. Non-saturated channel latency: 55 ms.
8

9. 1.6. From New-York, USA to California, USA.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. As usual, TCP remained at a level significantly
lower than the channel capacity. XTCP performed more than ten times faster than the standard TCP
protocol. Non-saturated channel latency: 76 ms.
9

10. 1.7. From Central America to United Kingdom.
Notes: All tests originating in Central America (Sections 1.7 – 1.9) possess one common
characteristic: the outgoing channel bandwidth is artificially limited. This means that the channel
bandwidth is not limited by the native capabilities of the networking hardware but rather explicitly
shaped by additional equipment or software which drops all packets transmitted at rates exceeding a
previously defined artificial limit. Because these drops are artificial (i.e., not caused by limitations of
the networking equipment), these drops are not preceded by increases in latency or other such
indications and are thus impossible to predict without existing knowledge of the artificial bandwidth
limit. In other words, the network characteristics remain stable right before the artificial limit is
reached because the artificial limit is usually much lower than the hardware capabilities of the
networking equipment. And because the network characteristics remain stable, XTCP receives no hint
that packet loss is impending and cannot limit throughput rates accordingly. Thus, XTCP requires
some time to align itself with the artificial limit and avoid unnecessary drops. During this time XTCP
experiences relatively frequent drops. Nevertheless, these drops seem to be significantly less than
those experienced by standard TCP, which similarly suffers from the artificial limits.
However tests taken in the reverse direction (to Central America: Sections 1.2, 1.5, 1.12) do not seem
to suffer from such artificial limits. There exist several complicated explanations of such
asymmetrical behavior but they are beyond the scope of this document.
The artificial limit is not the only problem here. The channel is also moderately congested which
results into unexpected drops and latency variations. Several drops caused by explicit rate shaping
were experienced until XTCP managed to detect the artificial limit. Once XTCP detected the limit,
further drops caused by explicit shaping were avoided. Latency variations and random drops caused
XTCP to decrease transfer rates for several times during transmission.
10

11. On the other hand TCP was incapable of ever reaching the artificial limit and thus transmitted at a
rate significantly lower than the available bandwidth. TCP also suffered severe and consistent
variation of transmission rates probably cause by periodic dropped packets. Overall, XTCP was 60%
faster than TCP.
Non-saturated channel latency: 121 ms.
11

12. 1.8. From Central America to New-York, USA.
Notes: In this test channel bandwidth is also artificially limited; however other network
characteristics allowed XTCP to detect the limit after only couple of minor losses at the very
beginning of transmission. Low channel latency allowed standard TCP to utilize almost the entire
available bandwidth. However, TCP faced frequent drops caused by the artificial limit and was not
capable of maintaining high transfer rates. Thus, TCP suffered periodic performance degradations.
The channel was initially lightly congested which caused slight XTCP transfer rate variation.
Congestion-related packet losses in the first half of XTCP transmission resulted into transfer rate
degradation but XTCP quickly recovered from it. Non-saturated channel latency: 55 ms.
12

13. 1.9. From Central America to California, USA.
Notes: As noted in Section 1.7 above an artificial bandwidth limit makes it harder for XTCP (and TCP
for that matter) to detect the available bandwidth. However, network latencies are relatively high
which prevents TCP from reaching the available bandwidth limit. XTCP has detected transfer rates
limit after several drops caused by explicit shaping and locked on it periodically probing the network
for additional available bandwidth. TCP was far from reaching the channel capacity and suffered
several random losses during transmission.
Our testing has generally shown that even in the worst cases (as exemplified by the sections 1.7-1.9
and section 1.5) XTCP is usually able to outperform TCP by a considerable margin and does not
degrade below the performance of TCP.
Non-saturated channel latency: 101 ms.
13

14. 1.10. From California, USA to United Kingdom.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity to packet
loss during initial exponential growth of send window. TCP, on the other hand transmitted at rates
much slower than the channel capacity. This allowed XTCP to finish more than 13 times faster than
standard TCP. Non-saturated channel latency: 141 ms.
14

15. 1.11. From California USA to New-York, USA.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity to packet
loss during initial exponential growth of send window. This allowed XTCP to finish around 10 times
faster than standard TCP. Non-saturated channel latency: 77 ms.
15

16. 1.12. From California, USA to Central America.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. TCP was capable of utilizing the better part of
the available bandwidth. However, XTCP's advanced window sizing algorithm alongside with
accurate bandwidth detection resulted into 42% performance gain. Non-saturated channel latency:
101 ms.
16

17. 2. Automated Linux tests
Unix-based systems are well known for rich variety of used TCP implementations. Previous section
described XTCP advantage over MS Windows TCP implementation. Tests represented in Section 2
were performed to compare XTCP to some other existing TCP modifications.
For those purposes a server running Ubuntu Linux Server OS was deployed within the same subnet
with one of our servers located at the United Kingdom. Testing process remained exactly the same
except for the fact that one of the sender systems was operated by Linux OS. Testing procedure
invokes successive downloads from Linux system and then from system running XTCP to the same
recipient. Both sender servers are located at the same subnet (physically same LAN) which provides
equal network conditions and lets us say testing was absolutely fair.
Three TCP implementations were tested against XTCP:
1. TCP Vegas – the ancestor of proactive congestion avoidance idea, which is widely used in a
variety of present TCP modifications.
2. TCP Cubic – the default TCP modification used in most Linux systems.
3. HTCP – advanced TCP modification developed for high bandwidth-latency product networks.
17

18. 2.1.1 From the United Kingdom to New-York, USA. TCP Vegas
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
packet loss during initial exponential growth of send window. XTCP was 5 times faster than TCP
Vegas. Non-saturated channel latency: 75 ms.
18

19. 2.1.2 From the United Kingdom to Central America. TCP Vegas.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. TCP Vegas was close enough to detecting
available bandwidth at the very start of transmission. However varying network latencies has
prevented TCP Vegas from maintaining a good performance during the whole transmission time.
Non-saturated channel latency: 121 ms.
19

20. 2.1.3 From the United Kingdom to California, USA. TCP Vegas
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
packet loss during initial exponential growth of send window. Due to high network latencies TCP
Vegas was incapable of transmitting at high rates. Moreover, latencies variation has prevented TCP
Vegas from reaching even this low theoretical limit. As a result, XTCP has overperformed TCP Vegas
more than 12 times. Non-saturated channel latency: 141 ms.
20

21. 2.2.1 From the United Kingdom to New-York, USA. TCP Cubic
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. XTCP has finished its’ transmission more
than 5 times faster than TCP Cubic. Non-saturated channel latency: 75 ms.
21

22. 2.2.2 From the United Kingdom to Central America. TCP Cubic.
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. TCP Cubic has shown its’ best and detected
the available bandwidth rather precisely. It, however, was always overshooting the upper limit
which in turn led to frequent losses and performance degradations. XTCP behaved more
accurately and provided a slight but noticeable performance gain. Non-saturated channel
latency: 121 ms.
22

23. 2.2.3 From the United Kingdom to California, USA. TCP Cubic
Notes: Network was initially highly congested during this test. XTCP has suffered some random
losses during bandwith detection. However it managed to reach maximum possible transfer rates
rather fast. TCP Cubic suffered moderate losses during all transmission time and did not perform
anywhere close to XTCP. Non-saturated channel latency: 141 ms.
23

24. 2.3.1 From the United Kingdom to New-York, USA. HTCP
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
packet loss during initial exponential growth of send window. Non-saturated channel latency: 75
ms.
24

25. 2.3.2 From the United Kingdom to Central America. HTCP
Notes: This shows normal flow of transmission. XTCP was able to detect channel capacity due to
sufficient latency growth during network saturation. HTCP has precisely detected transfer rates
limit but has overshot it for several times. It has slightly degraded HTCP performance. Non-
saturated channel latency: 121 ms.
25

26. 2.3.3 From the United Kingdom to California, USA. HTCP
Notes: This shows normal flow of transmission. XTCP was able to detect channel
capacity due to packet loss during initial exponential growth of send window. HTCP
experienced several random losses but was capable to maintain its’ transfer rates very
close to theoretical TCP limit. Non-saturated channel latency: 141 ms.
© MAINLINE NET HOLDING LIMITED
10.10.2010
26