Page 152 - ITU Kaleidoscope 2016

all packets will be forwarded to all available ports at br- Table 5: Detailed parameters of video file for
devops except the ingress port vnet1. Therefore, the file transferring experiments
network of the middle-box is reachable to both GIST-B and Video File Detailed
CHULA OpenStack VMs. The packets arrive from Parameters
devops_vlan will be forwarded only to vnet1 so that Video Format mp4
CHULA OpenStack VM data path network is reachable to Duration 10 minutes
Total File Size
843Mbytes
the middle-box. The reason is that we do not need to Resolution 3840 x 2610
transmit any traffic between GIST-B OpenStack VM and
CHULA OpenStack VM in this experiment. Therefore, we The parameters for Tsunami file-transfer protocol
cut out the routing between GIST-B OpenStack VM and are the default block size: 1024bytes (how large UDP
CHULA OpenStack VM in order to save the unnecessary blocks to use) and buffer size: 20Mbytes (size of ring buffer
bandwidth usages. in RAM) in this experiment. Tsunami protocol allows a
Another implementation to solve the fast time client to choose many parameters such as block size, buffer
responsiveness of GUI applications in accessing remote size, target file transfer rate, error threshold, and inter-
OpenStack VMs over OF@TEIN SDN cloud playground packet delay. However, in this experiment, we vary only
have been introduced in this paper. The limited access of target file transfer rates in order to investigate the effects of
GUI applications with X11 display over OF@TEIN varying target file transfer rates on transfer duration.
OpenStack VMs is limited for streaming video with large After completely received the video file in the
video resolution size. In order to solve out those issues, we middle-box, Tsunami protocol generates the analytic
have implemented the X11 Desktop Environment in results of file transferring. Among various output results
OpenStack VMs by using light weight X11 desktop from Tsunami analytic results, transfer duration, file data,
environment (LXDE) [15] which supports fast desktop throughput and final file rate (actual file transfer rate) have
performance for easy access GUI applications in the cloud. been used for analyzing our multi-path-based pre-fetch
Moreover, in order to access remotely to the implemented transfer of 4K-video experiments. After completely
Desktop Environments, we have installed an open source transferring a video file in the middle-box, the middle-box
remote desktop protocol (rdp) server called xrdp [16], a serves as a VLC streaming server to stream out the
free remote control software called tightvnc [17] and an downloaded video towards CHULA OpenStack VM in
open source implementation of the X Window system order to investigate the performance of the downloaded
called xorg [18]. There are three access methods for video stream. iPerf UDP test has been performed to check
OpenStack VMs: (1) access via xrdp without requiring port the available bandwidth between GIST-B, MY and
information, (2) access via tightvnc with requiring 5901 CHULA nodes. The bandwidth capacities of around
port access and (3) access via ssh with X11 display. For 422Mbps between OpenStack VM at GIST-B and middle-
accessing method 1 and 2, we can use either remote box VM at CHULA via Path 1 (GIST-B>MY>CHULA)
desktop connection with Window OSs or rdesktop with and around 456Mbps via Path 2 (GIST-B>CHULA) have
Linux/ Ubuntu OSs. been obtained from the test. The round trip time (RTT) via
the MY route is approximately 125ms and the RTT delay
3. RESULTS AND DISCUSSION from GIST-B to CHULA via the direct route is about
105ms.
The Big Buck Bunny, a 4K-animation video with Three scenarios have been tested for this multi-
a total file size of 843Mbytes, resolution 3840 x 2610 and path-based pre-fetch transfer of 4K-video experiments.
the duration of 10-minute has been used in this multi-path They are (1) multi-path with chunk size ratio (1:2sec)
chunked video exchanges (i.e., file transfer and streaming) which is periodically splitting by transmitting 1 second via
experiments. Tsunami file-transfer application [6] has been Path 1 and transmitting 2 seconds via Path 2 (2) using
installed on both GIST-B OpenStack VM and middle-box Path 1 alone (GIST-B>MY>CHULA) (3) using Path 2
VM in CHULA SmartX box. Since the purpose of this alone (GIST-B>CHULA). In order to investigate the
experiment is to investigate the effects of combining our effects of target file transfer rate on the transfer duration,
proposed multi-path file-transfer function and traditional we have varied the target file transfer rates of Tsunami
Tsunami file-transfer protocol, we have not modified the protocol to be 100, 200, 300, 400 and 500Mbps and have
default codes of Tsunami application. The Tsunami server tested three times with the same parameter settings for all
in GIST-B OpenStack VM starts the Tsunami server by three selected scenarios. The file transfer duration can be
using the command “tsunamid –port 46224 filename”. The computed from the following formula.
middle-box VM in CHULA SmartX box receives the video
file by using the command “tsunami set rate xxxM connect
serveripaddress get filename". The detailed parameter
settings of video file used for file transferring experiments
are shown in Table 5. Where:
Transfer Duration = File transfer duration between server
and client in seconds (s),

– 134 –