Fog computing is a distributed computing model as the middle layer between the cloud data center and the IoT device/sensor. It provides computing, network, and storage devices so that cloud based services can be closer to IOT devices and sensors. Cloud computing requires a lot of bandwidth, and the bandwidth of the wireless network is limited. In contrast, the amount of bandwidth required for “fog computing” is much less. In this paper, we improved a new protocol Peer Assistant UDT-Based Data Transfer Protocol (PaUDT), applied to Iot-Cloud computing. Furthermore, we compared the efficiency of the congestion control algorithm of UDT with the Adobe’s Secure Real-Time Media Flow Protocol (RTMFP), based on UDP completely at the transport layer. At last, we built an evaluation model of UDT in RTT and bit error ratio which describes the performance. The theoretical analysis and experiment result have shown that UDT has good performance in IoT-Cloud computing.
Internet of Things (IoT) and cloud computing are two very different technologies that are both already part of our life. IoT has received attentions for years and is considered as the future of Internet and also recognized as one of the most important areas of future technology and is gaining vast attention from a wide range of industries [
Fog computing is proposed to enable computing directly at the edge of the network, which satisfies the strongly requirements in processing big data influx in real-time and functioning the available bandwidth bounds. Fog computing is an extension of cloud computing to the emerging IoT. Fog computing is not made up of powerful servers but consisted of a variety of functional computers with weaker performance and more dispersive performance. It is connected to a variety of devices, including mobile phones, wearable devices, smart TV, smart homes, smart cars, and even smart cities. It is a novel paradigm realizing distributed computing, network services, and storage from beyond cloud computing data centers up until the devices. At present, the amount of equipment to collect data and the amount of data processing are increasing exponentially. Public cloud computing provides computing space for processing the data through a remote server. However, after uploading these data to remote servers for analysis, it will take time to transfer the results to the original location, which will slow down the process of real-time quick response. Fog computing is a newly introduced concept that aims to put the cloud closer to the end users (things) for better quality of service [
The transmission control protocol (TCP), the de facto transport protocol of the Internet, substantially underutilizes network bandwidth over high-speed connections with long delays [
With the size and complexity of cloud computing expanding, the architecture pattern is becoming more crucial on the performance of cloud computing. Different functions of cloud computing have different requirements for architecture patterns. The traditional UDT protocol is based on the Client and Server (C/S) mode, which is the most common distributed computing model [
Peer-to-peer (P2P) is a mature network that share computer resources and services through direct exchange of information between network nodes [
The rest of the paper is organized as follows. Section
New network devices are emerging and starting to connect. The data generated and sent to the cloud will increase exponentially. If storage and computing power follow Moore’s law, it means that they will double every 18 months. The relative speed of bandwidth seems to be much slower. Some research institutions estimate that the global bandwidth rate is growing less than 40% per year. This means that there will be more data to be sent to the cloud, but it will be constrained by bandwidth speed.
As a consequence, real-time and latency-sensitive computation service requests to be responded by the distant Cloud data centers often endure large round-trip delay, network congestion, service quality degradation, etc [
A lot of researches have been carried out by this protocol. Currently most interaction between the IoT devices and the supporting back-end servers is done through large scale cloud data centers, location awareness [
As main concepts of cloud computing, fog provides service which includes computation, storage, and networking services to end users, but in the end of the network. Despite the countless benefits of fog, the research in this field is still immature, and many researchers still are working on defining vision, basic notions, and challenges of fog computing [
An open research challenge is to explore the potential benefits of fog computing and IoT. In other words, one must study that quality of transparent service will be improved by having a layer of fog nodes between IoT and the cloud. Recent work addressed the design of TCP or UDP for transmission from mobile subscribers to edge clouds, to achieve a power-delay trade-off. Despite their solid contributions, the proposed approach is limited to the cellular network infrastructures. It assumes an IoT device can be only a User Equipment (UE) and that edge servers must be attached to base stations. Additionally, by not considering the cloud in the approach, scenarios where IoT-cloud or fog-cloud communication takes place are not handled.
For fast retransmission and fast recovery in IoT network, when an Iot client which we called sender receives three Native Acknowledgements (NAKs), sender will retransmit the lost packets right away and cut the ssthresh by half. At the same time, the algorithm sets congestion window CWnd equal to ssthresh and congestion voidance starts. The whole process is shown in Figure
The congestion control algorithm of TCP.
In Figure
The window based AIMD (additive increase multiplicative decrease) control algorithm of TCP suffers from random loss as the BDP increases to higher [
As illustrated in Figure
The UDT layer has five function components: the API module, the sender, the receiver, the listener, and the UDP channel. There are four data components: sender’s protocol buffer, receiver’s protocol buffer, sender’s loss list, and receiver’s loss list [
The API module is responsible for interacting with applications. When application sends data, the data packets are passed from sender’s buffer to UDP channel. On the other hand, receiver reads data from UDP channel and the packets will be reordered in receivers buffer. Receiver will check receiver’s loss list; if there are packets in receiver’s loss list, receiver will send a NAK to sender and when sender receives a NAK, the sender’s loss list will be updated, and sender sends this packet again until the receiver receives this packet. The main transmitting procedure is shown in Figure
UDT/CCC implementation.
UDT has two kinds of packets: the data packets and the control packets. The types of packets are distinguished by the first bit (flag bit) of the packet header, and when the flag is 0, it represents a data packet, and otherwise it represents a control packet. As shown in Table
UDT data packets header.
Packet sequence number | ||
---|---|---|
|
Message number | |
Time stamp | ||
Destination socket ID |
The control information is shown in Table
UDT control packets header.
Type | Revered | |
---|---|---|
Additional info | ||
Time stamp | ||
Destination socket ID | ||
Control information field |
In the structured P2P model, all information is scattered in different nodes of the network in the form of Hash list, and a huge distributed hash table (DHT) is constructed by the whole network (Figure
DHT technology is to add a separate DHT layer between the P2P network application layer and the network layer to locate and locate the resources of the P2P network. See Figure
Structure of DHT.
PaUDT communication in P2P mode.
The Kademlia model uses XOR operation as a measure of the distance between two nodes, assuming that there are two nodes in the Kademlia model, and the node ID is
The XOR distance is unidirectional in Kademlia models. Unidirectionally refers to any point
The following is the schematic diagram of the communication implementation for the PaUDT protocol of the P2P model.
We assume that there are two equal communication sides: server A and server B, and the black line part flow chart is the running process as server; part of the red line flow chart is the running process as the client.
In this section, we present the experimental results, which evaluate and characterize the RTMFP and PaUDT, in terms of congestion control algorithm.
RTMFP and UDT are end-to-end, connection-oriented, high reliability, and full-duplex protocol, and there are some same places. For example, they establish connections through four-way handshake, and both application layer protocols which are built on UDP in transport layer. Firstly, the type of data which is transported by RTMFP and UDT is different. RTMFP is used for the real-time and bulk data, but UDT only transports bulk data in the present circumstances. Secondly, unlike UDT, RTMFP is both supporting CS model and P2P model. The last and the major difference is the congestion control algorithm. Through the CCC between RTMFP and UDT, we know which protocol has higher efficiency. Section
A sender of RTMFP increases and decreases its CWnd according to ACK and loss (NAK or timeout) and according to the congestion control and avoidance algorithms [
From Sections
In order to contrast which protocol has higher efficiency, we design a experiment in a local area network. This experiment needs six computers; in three computers Linux system for UDT was installed and in others Win7 system for RTMFP is installed.
Install an open platform Adobe Flash Media Server (FMS). Then a computer as server uses FMS to transfer a video to clients, and clients receive the video; at the same time, one client use a capture tool (Wireshark) to capture packets.
After getting these packets, we use a filter tool in Wireshark to choose related packets (these packets are transferred by server), and calculate RTT according to the timestamp of packet’s header, through an open UDT source code to transfer the same video with RTMFP. As was stated above, we use Wireshark to capture related packets and calculate UDTs RTT. Contrast the RTT’s value of RTMFP and UDT.
As shown in Figure
The value of RTMFPs RTT.
Based on the system model, performance evaluation is mainly to solve the following problems:
(1) What conditions that network traffic need to satisfy to achieve optimal system performance.
(2) How different parameters influence optimal performance and we set two scenes to analysis the problem.
When UDT sends data packets, UDT always tries to pack application data into fixed size packets (the fixed size of data packets is the MSS that negotiated by sender and receiver), unless there is not enough data to be sent [
Before calculating the optimal MSS, we give some definitions.
If one bit in the frame is wrong, this frame is wrong, so we can get the wrong frame rate according to formula (
If
We need to calculate the average time of a frame transmission (
Now, if the length of file that we want to transport is sum, the average transmission delay equals the average transmission time of a frame multiply by the number of frames which are transported:
In order to acquire the optimal MSS, we need derivation of Delay:
If we set
And formula (
The relationship between RTT and MSS.
The relationship between MSS and the bit error ratio.
As shown in Figure
According to formula (
Although we can get a minimum transmission time using the optimal MSS in network in theory, there may be a practical problem that the MTU is less than the optimal MSS. If the optimal MSS is more than MTU, the packet (the size equals to the optimal MSS) must be fragmented in network layer. So in order to avoid fragment in network, we must set the most suitable MSS in upper layer. This asks us to compare the optimal MSS and the MTU and choose the minimum value as the most suitable MSS.
In order to complete this comparison, UDT is shown in Figure
UDT negotiates the MSS between sender and receiver.
In order to achieve the negotiation about MSS, we need to get the value of MTU in intermediate equipment. It is known that there are some structures in the head file of router, for example, reentry and
In the statements,
In our experiments, the MTU of the routers in the data link is 1500 bytes, and the optimal MSS also equals 1500 bytes. According to the information above, we can get that the real data packet size is 1500 bytes
In order to check whether the packet size does affect the UDT’s RTT and verify whether 1500 bytes is the most suitable MSS in our experiment’s environment, we design experiments as follows. In this experiment, we need two computers in a local area network, and every computer is both the sender and the receiver. In order to distinguish them, we call one computer A and the other computer B. Before the experiment, we need to modify the packet size in the open code. In the experiment, we set the packet size to 1500 bytes, 1300 bytes, and 512 bytes, respectively.
When application begins to send data, we record the value of RTT in computer A and computer B. After we get these values, we draw two diagrams like Figures
Relationship between UDTs RTT and packet size.
Relationship between PaUDTs RTT and packet size.
As shown in Figure
So we can get a conclusion that the different MSS has a relationship to RTT, and when the MSS equals the most suitable MSS, the average RTT is the smallest and the efficiency of packets which are sent or received is the highest.
There are two variables in PaUDT’s congestion control algorithm; one is MSS and the other is initwinsize. Section
Before verifying the influence of initwinsize to PaUDT, we introduce the influence to TCP.
Higher initwinsize will offer an advantage for TCP which is reduced latency, as described in formula (
In formula (
Figure
Relationship between initwinsize and latency.
Google Web study shows the effect of initWinseize on TCPs latency and from Figure
In order to confirm the relationship between initwinsize and latency, we set experiments as follows. First, we modify the initwinsize to 8, 16, 32, and 64, respectively.
From Figures
Relationship between PaUDT RTT and initialize window size (8).
Relationship between PaUDT RTT and initialize window size (16).
Relationship between PaUDT RTT and initialize window size (32).
Relationship between PaUDT RTT and initialize window size (64).
By analyzing the reasons for the dramatic changes in the RTT value, we found that the changes in intwize affect the value of CWnd. When the sender receives an ACK packet, the value of CWnd is calculated by formula (
From Figures
Fog computing concentrates data, data processing, and applications on devices at the edge of the network instead of storing them almost entirely in the cloud, as does cloud computing. With the expansion of the network scale, the traditional
The authors declare that they have no conflicts of interest.
This work is supported by National Natural Science Foundation of China (6167220961701170), China Postdoctoral Science Foundation funded project (2014M560439), Jiangsu Planned Projects for Postdoctoral Research Funds (1302084B), Scientific & Technological Support Project of Jiangsu Province (BE2016185), and Jiangsu High Technology Research Key Laboratory for Wireless Sensor Networks Foundation (no. WSNLBKF201701)