The 2014 International Conference on Advanced Technologies for Communications (ATC'14)

TCP Acceleration Technology for Cloud Computing:

Algorithm, Performance Evaluation in Real Network
Takashi Isobe, Naoki Tanida, Yuji Oishi, Kenichi Yoshida

Hitachi, Ltd., Central Research Laboratory
292, Yoshida-cho, Totsuka-ku, Yokohama-shi, Kanagawa-ken, 244-0817 Japan
e-mail: {takashi.isobe.fm, naoki.tanida.fv, yuji.oishi.aw}@hitachi.com

University of Tsukuba, Graduate School of Systems and Information Engineering
3-29-1, Otsuka, Bunkyo-ku, Tokyo, 112-0012 Japan
e-mail: s1430166@u.tsukuba.ac.jp, yoshida@gssm.otsuka.tsukuba.ac.jp

Abstract Cloud computing is becoming commonly used for

enterprise systems. Users utilize WAN, the Internet, or a wireless I. INTRODUCTION
network to access the cloud service. These networks often have Cloud computing is becoming commonly used for
large RTT and packet loss ratios (PLR), so if users communicate enterprise systems. Clouds aggregate IT devices and business
via TCP widely used for accessing cloud services, the throughput data to a data center and enable users to use them via networks.
decreases and the access quality of the cloud service deteriorates. Large-enterprise users build their own private clouds and can
Therefore, much TCP acceleration technology has been reduce the management cost by aggregating the IT devices and
developed in conventional research. The technology
business data managed at each site. Small-enterprise users can
conventionally proposed as RADIC-TCP [1] controls the
retransmission using negative acknowledgement (NACK)
also reduce the ownership and management costs of IT devices
returned from the remote receiver. It also uses a congestion by using the public cloud services offered by various providers.
algorithm that detects network congestion on the basis of the By using the public cloud services as much as necessary, the
change rate of PLR calculated by accumulating the lost segment user can utilize them flexibly. For example, while suppressing
written in NACK coming from the receiver. When the change an initial investment, the user can scale up the system in
rate of PLR is small, the sender judges that temporary loss is accordance with the growth of business.
caused by the congestion with burst traffic or bit error in the Users access the cloud service via WAN, the Internet, or a
wireless environment and continues to increase the throughput, wireless network from an unspecified number of places. When
not decrease the throughput. Thus, this technology can improve a user communicates via WAN or the Internet from remote
the utilization ratio of bandwidth without decreasing the sites or via a wireless network, round trip time (RTT) from data
throughput excessively. On the other hand, when the change rate transmission to acknowledgement reception is long.
of PLR is large, the sender judges that continuous loss is caused In addition, packet losses are caused over WAN or the
by the overuse of bandwidth and decreases the throughput at the Internet by the queue overflows of routers or switch in the
gap optimized in accordance with the scale of the network bottleneck where the line bandwidth decreases or by the
congestion. Therefore, this technology can follow the send confliction with other traffic. Also, packet losses are caused
bandwidth to the remaining bandwidth exactly while suppressing over the wireless network by bit error (figure 1). If users
the excess congestion in the network. In this research, we communicate via TCP, which is widely used in the cloud
developed TCP acceleration technology that controls the
services over these networks with large RTT and packet loss
retransmission using the standard selective acknowledgement
(SACK) in order to achieve the communication with normal
ratios (PLR), the throughput often decreases and the access
devices while supporting the congestion control using the same quality of the cloud service deteriorates.
algorithm as conventionally proposed TCP acceleration packet loss by bottleneck or
broadband packet loss by bit error
technology. However, our proposed TCP acceleration technology confliction with other traffic
may not work as intended depending on the occurrence interval sender
router
narrowband receiver
host broadband host
of packet losses in real network environments. Therefore, we /switch narrowband wireless
sender station receiver
evaluated this technologys behavior and effect in real network host
queue router
host
router /switch
environments. In the evaluation, a smartphone downloaded the /switch queue LTE/3G/WiFi
site A
data via a wireless network, the Internet, and a Japanese
queue receiver
academic backbone network (Science Information Network sender
router router host
router
(SINET)) from a Web server with TCP acceleration technology. host
/switch
/switch
/switch receiver
sender
In the evaluation using the LTE network with 40ms round trip host
queue WAN/Internet host
time, our proposed TCP acceleration technology enhanced the packet loss by bottleneck or
site C
throughput by up to three times. site B packet loss by bottleneck or
confliction with other traffic
confliction with other traffic
Keywords-component; TCP; protocol; delay; RTT; WAN; loss; packet stream
congestion control; throughput; bandwidth
Figure 1. Loss occurrence point in network

978-1-4799-6956-2/14/$31.00 2014 IEEE 714

 The 2014 International Conference on Advanced Technologies for Communications (ATC'14)

Thus, we have researched and developed TCP acceleration congestion control, our proposed TCP uses the same
technology to solve the problem of TCP throughput decreasing congestion control based on the change rate of PLR as the
over the network with large RTT and PLR and to improve the conventionally proposed TCP. Other TCPs congestion control
user quality in accessing the cloud service [1]. First, to speed is based on packet loss occurrence or delay. For the
up the interactive communication between the data center and transmission control, both conventional and proposed TCPs
the sites when utilizing a private cloud, we developed TCP send packets at the same interval on the basis of token bucket
acceleration technology that controls the retransmission using algorithm. Other TCPs transmission control is based on
negative acknowledgement (NACK) returned from the remote window size. We describe retransmission, congestion, and
receiver. It also uses a congestion algorithm that detects transmission control in Sections A - C.
network congestion on the basis of the change rate of PLR
calculated by accumulating the lost segment written in NACK. A. Retransmission control
Next, to support the speed-up of the communication from the In conventionally proposed TCP, the receiver sends
data center to the unspecified user devices when utilizing the NACK focusing on the place of lost data segment to the sender
public cloud, we developed TCP acceleration technology that only once after it detects the packet loss. The sender
controls the retransmission using the standard selective retransmits a packet with lost segment data estimated on the
acknowledgement (SACK) like other standard TCP [2] while basis of NACK (figure 2). If the receiver cannot receive the
supporting the congestion control using the same algorithm as retransmission packet within two RTTs after sending NACK,
the conventionally proposed TCP acceleration technology. The it retransmits NACK to encourage the retransmission.
new TCP acceleration technology does not require the On the other hand, in our proposed TCP, the receiver
installation of any devices to the remote sites or any software to continues to send SACK focusing on the place of partially
the receivers. Thus, it can accelerate the communication to received data segment to the sender the same as the other TCP
unspecified user devices. The cloud service providers can also after it detects the packet loss until the retransmission is
offer the TCP acceleration service as an additional service for
complete. The sender retransmits the packet with lost segment
their public cloud services. However, it may not work as
intended depending on the occurrence interval of packet losses data estimated on the basis of SACK (figure 2). In addition,
in the real network environments such as the wireless network the sender stores the place and the history of retransmitted data
[3]. Therefore, the performance must be evaluated over the real segments and compares them with a partially received data
network [4]. segment focused on by following SACK in order to judge if
In this research, we first explain the differences between the the lost data segment is newly generated. If so, the sender
conventionally proposed TCP acceleration technology and our retransmits it. While receiving SACK, the sender must
TCP acceleration technology controlling retransmission and continue to compare the retransmitted data segments with the
congestion with standard SACK. Next, we describe the partially received data segment focused on by SACK.
performance evaluation of our TCP acceleration technologys
B. Congestion control
behavior and its effect in the real network environments.
In conventional TCP, the congestion control is based on
II. OUR TCP ACCELERATION TECHNOLOGY the packet loss occurrence or communication delay.
TCP control is comprised of retransmission control, The congestion detection based on loss occurrence has the
congestion control, and transmission control. Table 1 details sender
conventional TCP
receiver sender
proposed TCP
receiver
the differences between our TCP acceleration technology and
the conventional TCP. For the retransmission control, the
conventionally proposed TCP uses NACK, but our proposed
TCP uses SACK, the same as the other TCPs. For the

TABLE I. COMPARISON OF PROPOSED AND CONVENTIONAL TCP

Congestion control
Retransmission Increase in Transmission
Detection Decrease in
control congestion control
congestion congestion
avoidance
Conventional Subtract current lost
NACK
TCP [1] Change rate of bandwidth from Linear or
Token size
PLR bandwidth transmitted exponential
Proposed TCP SACK
RTT ago Figure 2 Comparison of retransmission control
At a constant ratio
TCP Reno [2] Linear 100 0
(50%)
utilization ratio of bandwidth(%)

High-Speed TCP At a constant ratio 90 10background

Linear average 20
[5] (<50%) 80 20
Loss occurrence
At a constant ratio 70 30
Scalable TCP [6] trigger Exponential
(12.5%)
60 40
BIC TCP [7] By binary search
At a constant ratio
By cubic 50 50 temporary loss
CUBIC TCP [8] (10-20%) 40 60
SACK function Window size
According to 30 70
TCP Vegas [9] According to RTT
Communication RTT 20 80
delay standard TCP (RTT10ms)
According to 10 90average 25
Fast TCP [10] According to RTT decrease at a constant ratio
RTT
0 100
Loss occurrence
Linear or 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
and At a constant ratio
CTCP [11] according to time (second)
communication or according to RTT
RTT
delay
Figure 3. Congestion control based on loss occurrence

715
 The 2014 International Conference on Advanced Technologies for Communications (ATC'14)

problem of the throughput being excessively decreased by the
temporary loss caused by the confliction with burst traffic and
the bit error in the wireless network. As shown in figure 3,
TCP detecting the congestion based on loss occurrence cannot
utilize the remaining bandwidth.
On the other hand, the congestion detection based on
communication delay has difficulty in estimating the scale of
congestion because the communication delay is not in
proportion to the scale of the congestion. Even if the queue
overflows at a switch or router and many packets are lost, the
communication delay does not increase. Thus, the congestion
control based on communication delay fails to detect the
congestion and continues to place too much load on the
network. In contrast, when the queue accumulates many
packets, the congestion control based on communication delay
decreases the throughput before the packet loss occurs, while
the congestion control based on loss occurrence increases the
throughput. Therefore, the congestion control based on
communication delay is outperformed by the congestion
control based on loss occurrence such as TCP Reno [2].
Proposed TCP acceleration technology detects the
congestion based on the change rate of PLR and classifies
types of packet loss as temporary or continuous. Temporary
loss is caused by the confliction with burst traffic or the bit
error in the wireless network. Continuous loss is caused by the
overuse of bandwidth. When the change rate of PLR is small,
proposed TCP judges that temporary loss occurs and continues
to increase the throughput. On the other hand, when the
change rate of PLR is large, proposed TCP judges that
continuous loss occurs and decreases the throughput at the gap
optimized in accordance with the scale of the network
congestion. The transmit bandwidth is reduced to the value
obtained by subtracting the current loss bandwidth from the
previous transmit bandwidth. Hereby, this technology can
follow the throughput to the remaining bandwidth and
improve the utilization efficiency of the bandwidth.
Figure 4 shows the details of congestion control. When
the change rate (p) of PLR (p) is under the preset threshold
(k), the throughput continues to increase (state 1). If the
change rate of PLR exceeds the threshold k, proposed TCP
judges that the bandwidth transmitted one RTT ago exceeds
the bottleneck bandwidth and continuous loss occurs. This
reduces the transmit bandwidth to the value obtained by
subtracting the current loss bandwidth from the bandwidth
transmitted one RTT ago causing the congestion (state 2).
After this, the throughput continues to decrease until the
retransmission is completed. If no packet loss occurs in state 2,
the throughput becomes constant in state 2. In contrast, if
some packet losses occur in state 2, the throughput decreases
in state 2. If the change rate of PLR becomes under the
threshold k in state 2, the throughput increases again (state 1).
The congestion control based on the change rate of PLR
requires the calculation of PLR at the senders. The method for
calculating PLR is different for conventional and proposed
TCPs.
Conventional TCP calculates PLR by accumulating the
size of lost segment data written in NACK received from the
receivers (figure 5). On the other hand, proposed TCP
calculates PLR by accumulating the size of lost data segments
estimated from the partially received data segment written in
SACK returned from the receivers (figure 5). To estimate the
lost segment data, the sender must record the partially received
data segment and compare the record with the partially
received data segment written in newly received SACK.
C. Transmission control
Conventional TCP [2, 5-11] manages the thresholds called
the receiver window (rwnd) and congestion window (cwnd)
[2], which limit the size of data that a sender can send without
receiving an acknowledgement (ACK) packet from a receiver.
The sender cannot send the data exceeding window size for
the interval of one RTT until ACK returns from the receiver,
so the throughput is limited up to the value obtained by
dividing window size by RTT. If a window is small at large
conventional TCP
sender receiver sender
proposed TCP
receiver
estimate lost segment
from a NACK
estimate lost segment
from multiple SACKs

throuthput state 1 state 2 sate 1 Figure 5. Comparison in loss segment estimation

increase decrease increase
conventional TCP proposed TCP
exceeding bandwidth
bandwidth sent before one RTT sender receiver sender receiver
RTT current lost bandwidth
window size token size 1msec
send size .
loss ratio increases one RTT after exceedance for a RTT RTT token size 1msec
time .
loss ratio p by intervals of a RTT RTT RTT cant send even if send size
line is not in use for 1msec.
temporary loss continuous loss
temporary loss window size
time
change rate of loss ratio ? p RTT
exceedance of threshold k
threshold
0 k
speed up
time
Figure 4. Congestion control based on the change rate of PLR Figure 6. Comparison in transmission control

716
 The 2014 International Conference on Advanced Technologies for Communications (ATC'14)

RTT, the sender is unable to send data over a long period even III. EVALUATION IN THE REAL NETWORK
if the communication line is not in use (figure 6). Thus, large We needed to prove that our proposed TCP acceleration
RTT reduces the throughput. technology worked as intended independent of the occurrence
The maximum window size is limited by the buffer size of interval of packet losses in real network environments.
the receiver or sender, whichever is smaller. If the buffers are Therefore, we evaluated the speed-up effect of proposed TCP
large, the sender can use a large window. However, acceleration technology by transferring data to a smartphone
excessively large windows cause the burst traffic, which via a real network. In the evaluation, we used various wireless
reduces the throughput due to the frequent packet loss. networks, carriers, smartphones, network paths, and
Both conventional and proposed TCPs limit the send data congestion levels and then evaluated the speed-up effect in the
size by using the token size (the size of data allowed to be sent various environments.
for each constant interval of 1 millisecond) instead of
congestion window (the size of data allowed to be sent for A. Evaluation using LTE or 3G network
each RTT). Even if RTT increases, the size of data allowed to We evaluated the throughput by transferring the data to a
be sent for each RTT increases in accordance with RTT. smartphone using a commercial LTE or 3G network of a
Therefore, our TCP can use the throughput efficiently when carrier [12] at the sites of Hitachi, Ltd. in Yokohama, Japan.
the communication line is not in use (figure 6). The network configuration and device specifications are
Whether a packet is sent or not is decided by using the shown in figure 7 and table 2.
token bucket algorithm. The token equivalent to the size of The Web server using a general purposes processor [13]
data allowed to be sent for 1 millisecond is accumulated into a and a commercial OS [14] worked with our proposed TCP
token bucket at each interval. When the amount of the tokens acceleration function and was connected to the Internet with a
accumulated in the token bucket reaches a packet length, the 100Mbps commercial access line [15] via a commercial ISP
transmission of a packet is allowed. After the packet is network [16]. We accessed the server from a smartphone
transmitted, the token equal to the packet length is removed installed with a commercial OS [17] and measured the average
from the token bucket. This algorithm makes it possible to throughput needed to download 10MB data by HTTPS. The
send packets smoothly at a constant interval. Web server communicated using Compound TCP [11] when
TCP acceleration technology was not used.
Hitachi., Ltd. Hitachi., Ltd.
(Yokohama, Japan) (Yokohama, Japan) Figures 8 and 9 show the change of the throughput when
Download 10MB file over HTTPS the server transferred data to a smartphone when using a 3G or
access line[15]
100Mbps
Internet
LTE
LTE network and switching TCP acceleration function on/off.
ISP[16]
/3G[12] smartphone Our TCP acceleration technology enhanced the throughput
Web server with
TCP acceleration function
with OS [17] by 2.3 times from 1.44Mbps to 3.35Mbps in the 3G network
Figure 7. Configuration using LTE or 3G network
and by 1.4 times from 1.82Mbps to 2.53Mbps in the LTE
network. In both 3G and LTE networks, we achieved the
speed-up effect.
TABLE II. EXPERIMENTAL SPECIFICATION
Device Details The 80ms RTT in the 3G network was larger than the RTT
CPU: general purpose processor 2.7-3.4GHz, cache 4MB [13] 50ms in the LTE network, but nevertheless 3.35Mbps
Web server Memory: DDR3-1333MHz 8GB
OS: commercial PC OS [14] throughput in the 3G network was larger than 2.53Mbps
Smartphone
CPU: general purpose processor
OS: commercial smart phone OS[17, 18]
throughput in the LTE network. The throughput is estimated to
alternate in accordance with not only the type of wireless
throughput
10Mbps TCP acceleration OFF 1.44Mbps (RTT>80ms) network but also the number of users and the amount of the
speed up 2.3 times communication facilities invested in the area.
TCP acceleration ON 3.35Mbps (RTT>80ms)
Hitachi., Ltd. Hitachi., Ltd.
5Mbps (Yokohama, Japan) (Yokohama, Japan)
Download 10MB file over HTTPS
access line[15] Internet
100Mbps ISP [16] LTE[19]
0Mbps Web server with smartphone
TCP acceleration function OS[18]
0 10 20 30 40 50 60 0 10 20 30 40 50 60
time (second)
Figure 10. Configuration changing wireless carrier and devices
Figure 8. Speed-up effect of TCP acceleration in 3G network

throughput TCP acceleration OFF 1.82Mbps (RTT>50ms) throughput TCP acceleration OFF 10.7Mbps
speed up 1.3 times 20Mbps
10Mbps speed up 1.4 times 20Mbp
TCP acceleration ON 14.3Mbps
TCP acceleration ON 2.53Mbps (RTT>50ms) s

5Mbps 10Mbp 10Mbps

s

0Mbps 0Mbps 0Mbps

0 10 20 30 40 50 0 10 20 30 40 50 0 10 20 30 40 50 60 70 80 0 10 20 30 40 50 60 70 80 90100110
time (second) time(second)
Figure 9. Speed-up effect of TCP acceleration in LTE network Figure 11. Speed-up effect in changing carrier and device

717
 The 2014 International Conference on Advanced Technologies for Communications (ATC'14)

B. Evaluation using other carriers and devices
We evaluated the speed-up effect of our proposed TCP in
the same way as in Section A by changing the OS of the
smartphone [18] and the carrier of wireless network [19]. The
network configuration is shown in figure 10.
Figure 11 shows the change of the throughput when the
server transferred data to a smartphone twice by using the LTE
network [19] and switching the TCP acceleration function
on/off.
Even when we changed the wireless network carrier and
smartphone OS, our TCP acceleration technology enhanced the
throughput by 1.3 times from 10.7 Mbps to 14.3 Mbps.
C. Evaluation using SINET
32Mbps. Our TCP acceleration technology did not seem to
cause excessive congestion in the wireless network.
In the experimental environment with the same conditions,
the speed-up effect was about 3.0 from 6.9Mbps (RTT 40ms,
loss 0.16%, TCP acceleration off) to 23Mbps (RTT 40ms, loss
0.51%, TCP acceleration on). Thus, the speed-up effect in the
real network was as good as that in the experimental
environment.
D. Evaluation in crowded wireless network
We moved the place where the smartphone accessed the
server to Yamanote-Line stations in Tokyo where the wireless
Univ. of Tsukuba Yamanote-Line stations
(Tokyo, Japan) (Tokyo, Japan)

We moved the Web server including the TCP acceleration Download 10MB file over HTTPS
function from Hitachi, Ltd. to the University of Tsukuba VPN Internet
1Gbps 10Gbps
campus in Tokyo, Japan, and evaluated the speed-up effect SINET [20] LTE[19]
smartphone
when the smartphone accessed the server. The network Web server with
TCP acceleration function
Univ. of Tsukuba
OS [18]
(Tsukuba, Japan)
configuration is shown in figure 12.
The Web server is connected at 1Gbps via VPN to the Figure 14. Configuration using crowded wireless network
University of Tsukuba LAN in Tsukuba City, which is
connected at 10Gbps via Science Information Network
(SINET) [20] to the Internet. At the Tokyo campus of the
University of Tsukuba, we accessed the server from a
smartphone with a commercial OS installed [18] and measured
the average throughput needed to download 10MB data by
HTTPS.
Figure 13 shows the change of the throughput when the
server transferred data to the smartphone eight times when
using the LTE network [19] and switching TCP acceleration Figure 15. Speed-up effect in accessing from Tokyo station
function on/off.
Even when we changed the network from ISP to SINET,
our TCP acceleration technology enhanced the throughput by
3.0 times from 4.9 Mbps to 14.7 Mbps.
PLR when transferring data increased from 0.164% to
0.512% by keeping the TCP acceleration function on. This was
because the confliction with other communication occurred
more frequently as the throughput increased. The increase of
PLR was 0.348%, and the increase of lost bandwidth was
51kbps, which occupied 0.16% of maximum throughput Figure 16. Speed-up effect in accessing from Shinagawa station
Univ. of Tsukuba
(Tokyo, Japan) Univ. of Tsukuba
(Tokyo, Japan)
Download 10MB file over HTTPS

VPN Internet
1Gbps 10Gbps
SINET [20] LTE[19]

Web server with Univ. of Tsukuba smartphone

TCP acceleration function (Tsukuba, Japan) OS [18]

Figure 12. Configuration using SINET

Figure 17. Speed-up effect in accessing from Shibuya station

Figure 13. Speed-up effect in using SINET Figure 18. Speed-up effect in accessing from Shinjuku station

718
 The 2014 International Conference on Advanced Technologies for Communications (ATC'14)
network was congested: Shinagawa, Shibuya, Shinjuku, and
Tokyo station itself. We also evaluated the speed-up effect of
our proposed TCP in the same way as in Section C. The
network configuration is shown in figure 14. Evaluation was
done when the wireless network was thought to be congested.
Figures 15-18 show the change of the throughput when the
server transferred data to the smartphone at Tokyo, Shinagawa,
Shibuya, and Shinjuku stations multiple times using the LTE
network [19] and switching the TCP acceleration function
on/off. At Tokyo, Shibuya, and Shinjuku stations, evaluation
was done two, five and three times.
Even if we moved the smartphone accessing the server to a
place where the wireless network was congested, our TCP
acceleration technology enhanced the throughput by 1.2-2.3
times.
Furthermore, at Shibuya and Shinjuku stations, the
throughput often decreased near 0Mbps. This was because the
degree of congestion at these stations was higher than that at
the other stations and the number of users exceeded the upper
limit of the wireless base station.
E. Evaluation using Wi-Fi network
We used a Wi-Fi network as the wireless network to access
the server from the smartphone and evaluated the speed-up
effect of our proposed TCP in the same way as Section C. The
network configuration is shown in figure 19. For the Wi-Fi
network, we used 802.11g with a maximum physical
bandwidth of 54Mbps.
Figure 20 shows the change of the throughput when the
server transferred data to a smartphone in Yokohama, Japan,
five times when using the Wi-Fi network and switching TCP
acceleration function on/off.
Even when we used the Wi-Fi network as the wireless
network to access the server from the smartphone, our TCP
acceleration technology enhanced the throughput at 1.56 times.
IV. CONCLUSION
We have developed TCP acceleration technology to solve
the problem of TCP throughput decreasing over the networks
with large round trip time (RTT) and packet loss ratios (PLR)
and to improve the user quality of cloud access. We developed
TCP acceleration technology that controls the retransmission
using the standard selective acknowledgement (SACK) to
Univ. of Tsukuba (Tokyo, Japan)
Download 10MB file over HTTPS
VPN
Internet
1Gbps 10Gbps
SINET [20]
Web server with
Univ. of Tsukuba
TCP acceleration function
(Tsukuba, Japan)
Figure 19. Configuration using Wi-Fi network
throughput TCP acceleration OFF 4.96Mbps
speed up 1.56 times
TCP acceleration ON 7.75Mbps
ON
ON OFF
OFF OFF
ON
OFF
0 100 200 300 400
time (second)
Figure 20. Speed-up effect in using Wi-Fi network
accelerate the communication between a data center and the
normal user devices while supporting the congestion control
using the same algorithm as the conventional TCP acceleration
technology [1].
Our TCP acceleration technology does not require the
installation of any devices to the remote sites or any software to
the receivers. Thus, it can accelerate the communication to
unspecified user devices. The cloud service providers can also
offer the TCP acceleration service as an additional service for
their public cloud services.
In this research, we first showed the differences between
the conventional TCP acceleration technology and our TCP
acceleration technology controlling retransmission and
congestion with standard SACK. Next, we evaluated this
technologys behavior and effect in the real network
environments.
In the evaluation, a smartphone downloaded the data over
wireless networks, the Internet, and SINET via a TCP
acceleration device from a server placed in a university campus.
In the evaluation using the LTE network with 40ms RTT, we
enhanced the throughput by up to three times. Furthermore, we
used various wireless networks, carriers, smartphones, network
paths, and the congestion levels and then evaluated the speed-
up effect in the various environments. Our TCP acceleration
technology enhanced the throughput by 1.2-3.0 times.
REFERENCES
[1] T. Isobe et al., RADIC-TCP: High-Speed Protocol Applied for Virtual
Private WAN, IEEE ICT, pp. 544 549, May. 2011
[2] M. Allman et al., TCP Congestion Control, IETF RFC2581, Apr. 1999
[3] H. Chaoxin et al., WiTracer: A novel solution to improve TCP
performance over Wireless network, IEEE IWCMC, pp. 450-455, July
2013
[4] J. Kellokoski, Real-life multipath TCP based make-before-break
vertical handover, IEEE ISCC, pp. 252-256, July 2013
[5] S. Floyd, HighSpeed TCP for Large Congestion Windows, IETF
RFC3649, Dec. 2003
[6] T. Kelly, Scalable TCP: Improving Performance in High Speed Wide
Area Networks, ACM SIGCOMM, Apr. 2003
[7] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion Control
for Fast Long-Distance Networks, IEEE INFOCOM, Mar. 2004
[8] L. Xu et al., CUBIC: A New TCP-Friendly High-Speed TCP Variant,
Workshop on Protocols for Fast Long Distance Networks, Feb. 2005
[9] Lawrence S. Brakmo, TCP Vegas: End to End Congestion Avoidance
on a Global Internet, IEEE Journal on Selected Areas in
Yokohama, Japan Communications, vol. 13, No.8, Oct. 1995
[10] Jin, C. et al., FAST TCP: Motivation, Architecture, Algorithms,
Performance, IEEE INFOCOM, Mar. 2004
WiFi [11] Kun Tan et al., A Compound TCP Approach for High-speed and Long
802.11g Distance Networks, IEEE INFOCOM, April 2006
smartphone
OS [18]
[12] Docomo LTE/3G, https://www.nttdocomo.co.jp/, March 2014 access
[13] Intel Core i7 processor, http://www.intel.co.jp/content/www/jp/ja/
processors/core/core-i7-processor.html, March 2014 access
20Mbps
[14] Microsoft OS Windows 7, http://windows.microsoft.com/ja-jp/
windows/windows-help#windows=windows-8, March 2014 access
ON
[15] NTT B flets, https://flets.com/bflets/, March 2014 access
[16] Plara Internet Access Service, http://www.plala.or.jp/, March 2014 access
OFF ON 10Mbps
[17] Google Android OS, https://www.google.co.jp/mobile/android/, March 2014
access
[18] Apple iOS, http://www.apple.com/jp/ios/, March 2014 access
0Mbps
500 600 [19] KDDI AU LTE, http://www.au.kddi.com/, March 2014 access
[20] SINET, http://www.sinet.ad.jp/case/tsukuba2, March 2014 access
719