Performance Analysis of a Novel TCP Protocol Algorithm Adapted to Wireless Networks

: As telecommunication systems evolve towards new-generation architectures, likewise, new protocols are created in order to improve e ﬃ ciency. One of these protocols is Transmission Control Protocol (TCP), which controls the transmission bit rate in function of network congestion. Nevertheless, in wireless communications, there appear problems such as noise and interference, for which TCP was not designed. Based on these problems, there exist some methods trying to mitigate congestion, such as explicit loss notiﬁcations and the use of end-to-end codiﬁcation. The aim of this work was to propose a wireless TCP protocol improvement, considering a negative acknowledgment (NACK), which allows to di ﬀ erentiate between losses due to congestion and losses due to wireless channel issues. NACK employs a small protocol packet and produces improvement in the quality of service metrics. The experiments were carried out in in-door and out-door environments, over an online video game scenario, and over a long-distance wireless link between two islands. The average results show a 25-percent delay improvement and a 5-percent jitter improvement when compared to the original TCP Reno protocol, while for throughput a 90-percent improvement was achieved for distances between 100 and 414 m.


Introduction
The Transmission Control Protocol (TCP) was originally designed for wired networks, by interpreting packet loss (PL) as congestion consequence; meanwhile, in wireless networks, PL is also caused by issues in the communication channel, such as interference, multi-path fading, mobility, and reflections, which may produce a PL misinterpreting [1]. In order to avoid congestion, TCP employs cumulative Acknowledgments (ACK); in this sense, the receptor sends ACKs to indicate that a packet was successfully received and to specify that it is expecting the next one. If the transmitter undetected an ACK, the packets are re-sent or the connection is disrupted [2]. TCP can use four algorithms for Congestion Window (CWND) control: Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery. These algorithms seek to achieve a high network performance and to avoid collapse by congestion. Slow Start increases exponentially the transmission bit rate until a packet loss is detected. From this point, the Congestion Avoidance algorithm increases the transmission bit rate linearly, and when three duplicate ACKs are detected, TCP reduces the transmission bit rate by half. Meanwhile, Fast Retransmit and Fast Recovery allow to resend packets immediately when three duplicate ACK (DUPACK) are detected. The transition from one algorithm to another occurs when PL is detected [3]. Although CWND control algorithms achieve their goal in wired networks, in wireless networks, and TCP-Westwood and showed that the proposed ML-LDA has 98% packet loss classification accuracy in wireless channel environments, and average throughput is greatly improved compared to the others congestion controls.
In this context, the aim of this paper is to describe the development of a novel simple TCP protocol algorithm adapted to wireless networks. Specifically, we address improvements in the wireless TCP. In this paper, we will consider all stages related to performance evaluation, including a mathematical analysis, configuring our proposal by modifying the linux kernel, emulations, and finally testbed analysis in real scenarios. Our primary hypothesis is that by inserting a negative acknowledgment (NACK) flag inside the TCP header, naming this TCP modification as "TCP-NACK", we will prevent the misinterpretation of PL due to channel instability, as well as PL due to congestion, thus reaching a better performance. In this sense, we consider the ELN concept of retransmitting corrupted packets without the CWND reduction.
The rest of the paper is organized as follows: In Section 2, we describe the methods and materials used for TCP-NACK design, emulation, and evaluation. Section 3 presents the experimentation process and how the results were obtained. Section 4 presents the discussion of the results when compared to generic TCP algorithms. Finally, our conclusion and future works are presented in Section 5.

Materials and Methods
This section shows the tools and techniques used for the TCP-NACK protocol development, including its mathematical analysis, implementation and testbed experimentation.

Mathematical Analysis
We start the analysis from a mathematical modeling of the Generic TCP behavior in order to develop an adaptation for corrupted packets retransmission without the CWND size reduction (i.e., the TCP-NACK performance idea) [16]. For this purpose, Slow Start and Congestion Avoidance algorithms were used for modeling the Generic TCP protocol in their Reno and Westwood version.
At the TCP layer, we use the maximum packet size (MSS) of N TCP bits. The sender releases packets into a limited FIFO buffer that can hod up B packets. The packets are then sent over a single bottleneck link with a speed of R p = R b /N TCP packets per second, where R b is the bit rate of the TCP layer. Figure 1 shows the ω-th cycle evolution of the congestion window between two indications of acknowledgements (ACKs). If W 0 is the initial congestion window, the first burst contains exactly W 0 packets, the second W 0 + 1 packets and so on. The congestion window is increased by one at the end of each burst. The index of the first packet lost in the cycle is denoted by n l . If x is the burst where the lost one occurs, in the burst x + 1 the congestion window is reduced for W 0(ω+1) and this value depends on the estimate bandwidth for TCP Reno or TCP Westwood [5]. showed that the proposed ML-LDA has 98% packet loss classification accuracy in wireless channel environments, and average throughput is greatly improved compared to the others congestion controls.
In this context, the aim of this paper is to describe the development of a novel simple TCP protocol algorithm adapted to wireless networks. Specifically, we address improvements in the wireless TCP. In this paper, we will consider all stages related to performance evaluation, including a mathematical analysis, configuring our proposal by modifying the linux kernel, emulations, and finally testbed analysis in real scenarios. Our primary hypothesis is that by inserting a negative acknowledgment (NACK) flag inside the TCP header, naming this TCP modification as "TCP-NACK", we will prevent the misinterpretation of PL due to channel instability, as well as PL due to congestion, thus reaching a better performance. In this sense, we consider the ELN concept of retransmitting corrupted packets without the CWND reduction.
The rest of the paper is organized as follows: In Section 2, we describe the methods and materials used for TCP-NACK design, emulation, and evaluation. Section 3 presents the experimentation process and how the results were obtained. Section 4 presents the discussion of the results when compared to generic TCP algorithms. Finally, our conclusion and future works are presented in Section 5.

Materials and Methods
This section shows the tools and techniques used for the TCP-NACK protocol development, including its mathematical analysis, implementation and testbed experimentation.

Mathematical Analysis
We start the analysis from a mathematical modeling of the Generic TCP behavior in order to develop an adaptation for corrupted packets retransmission without the CWND size reduction (i.e., the TCP-NACK performance idea) [16]. For this purpose, Slow Start and Congestion Avoidance algorithms were used for modeling the Generic TCP protocol in their Reno and Westwood version.
At the TCP layer, we use the maximum packet size (MSS) of NTCP bits. The sender releases packets into a limited FIFO buffer that can hod up B packets. The packets are then sent over a single bottleneck link with a speed of Rp = Rb/NTCP packets per second, where Rb is the bit rate of the TCP layer. Figure 1 shows the ω-th cycle evolution of the congestion window between two indications of acknowledgements (ACKs). If W0 is the initial congestion window, the first burst contains exactly W0 packets, the second W0 + 1 packets and so on. The congestion window is increased by one at the end of each burst. The index of the first packet lost in the cycle is denoted by nl. If x is the burst where the lost one occurs, in the burst x+1 the congestion window is reduced for W0(ω+1) and this value depends on the estimate bandwidth for TCP Reno or TCP Westwood [5]. We considered that the congestion window is increased by one at the end of each burst. Therefore, the congestion window for the x-th burst is given by We considered that the congestion window is increased by one at the end of each burst. Therefore, the congestion window for the x-th burst is given by When the congestion does not exist, the congestion window has a linear increase for every round-trip times (RTT) seconds, given by where τ p is the propagation time.
During a cycle, ACKs in the same burst arrive 1/R p seconds apart while consecutive bursts arrive RTT second apart, until the pipe capacity, W C = R p RTT, is reached and c = W C − W o . After this point, ACKs arrive continuously every 1/R p seconds.
Since a packet loss would occur one the buffer is full, the maximum window size a connection can achieve is given by Let n x the index of the first packet in the x-th burst, given by The index of the packet dropped due to buffer overflow is denoted by n of and is given by: where n cb is the first packet in the burst x = c + B, for the maximum window size W max . Let x n be the number of burst that contain the packet number n and r x n the offset of the packet in the burst x n . These parameters for 1 ≤ n ≤ n of are expressed as and r x n = n − n x n The instant in which the n-th ACK is received is given by where c = W C -W 0 xº is the burst where the pipe capacity occurs. For the TCP Reno at the beginning of a generic cycle ω, the start threshold according to the value of the estimate bandwidth at the end of the previous cycle for congestion avoidance is given by where n l is the ACK missed at the end of the cycle ω − 1.
The TCP Westwood sets the slow start threshold according to the value of the estimated bandwidth at the end of the previous cycle using the following expression [5]: where where α is related to the cut-off frequency of the low pass filter and b n is the bandwidth information carried by the n-th ACK, expressed as The evolution of the initial congestion window size, in each cycle, can be modelled as a Markov process. W 0(ω) depends only on W 0(ω−1) and n l(ω−1) . The transition probability from W 0(ω−1) = i for W 0(ω) = j is given by where the probability that the packet n is dropped, given that the initial window W 0 = i, and is expressed as (14) where P packet,TCP is the TCP packet error probability. Finally, using (8) and (14) the throughput realized by the system is given by [5] where π (W 0 =i) is the asymptotic probability of the initial window size W 0 . Then, we added in (16) the packet loss probability effect due to wireless issues in order to fit the model to the TCP-NACK protocol behavior proposed. Therefore, if the packets are corrupted due to the wireless channel, these errors are recognized by NACKs, and the CWND increases normally (i.e., until the depletion of the receptor buffer). Finally, the TCP-NACK θ is defined as

TCP-NACK Linux Implementation
We chose and modified the TCP/IP stack from Linux 2.6.32 source code for the TCP-NACK implementation based on TCP-Reno protocol, since it is an open access and open source operating system [17]. Specifically, we modified the files inside the "include" and "net" directories, which are distributed within the Linux kernel as showed in Figure 2.

TCP Sockets
In Linux, the different communication protocols are implemented by sockets, which works as a common interface between the user and the different systems files and device systems. Three data structures for the sockets handling are used, the first is called "socket buffer", which store the packet information, the second is called "socket", which register the open connections, and the last is called "sock", which maintains the open connections state [17].

TCP Sockets
In Linux, the different communication protocols are implemented by sockets, which works as a common interface between the user and the different systems files and device systems. Three data structures for the sockets handling are used, the first is called "socket buffer", which store the packet information, the second is called "socket", which register the open connections, and the last is called "sock", which maintains the open connections state [17].

Data Sending by TCP
TCP is a protocol that ensures the reliable transmission by executing a data flow management. Therefore, there are three principal functions inside the Linux kernel that intervene in the data sending process and flow management [17].
1. tcp_sendmsg: which copies the user space data to the Linux kernel space, then it is assigned to the "socket buffer" and divided in smaller packets.
2. tcp_send_skb: which organizes the data in "socket buffer" for the transmission queue, and decides whether the transmission can take place or not.
3. tcp_transmit_skb: which builds the TCP header and sends the packets to the network layer.

Data Reception by TCP
Received packets must be transferred from the network layer to the transport layer for the TCP header and data processing by the following functions.
1. tcp_v4_rcv: which verifies the packet integrity, it checks if the packet is properly destined, process the transport layer checksum and removes the IP header. 2. tcp_v4_do_rcv: which verifies that the received packet has a complete header and checks the current TCP connection state. 3. tcp_rcv_established: If the current TCP connection state is "ESTABLISHED", it processes the received packets and copies the data to the user space. If the packets are error-free, a fast process denominated "fast path" is executed, otherwise a "slow path" process is executed.

Data Sending by TCP
TCP is a protocol that ensures the reliable transmission by executing a data flow management. Therefore, there are three principal functions inside the Linux kernel that intervene in the data sending process and flow management [17].

1.
tcp_sendmsg: which copies the user space data to the Linux kernel space, then it is assigned to the "socket buffer" and divided in smaller packets.

2.
tcp_send_skb: which organizes the data in "socket buffer" for the transmission queue, and decides whether the transmission can take place or not.

3.
tcp_transmit_skb: which builds the TCP header and sends the packets to the network layer.

Data Reception by TCP
Received packets must be transferred from the network layer to the transport layer for the TCP header and data processing by the following functions.

1.
tcp_v4_rcv: which verifies the packet integrity, it checks if the packet is properly destined, process the transport layer checksum and removes the IP header. 2.
tcp_v4_do_rcv: which verifies that the received packet has a complete header and checks the current TCP connection state. 3.
tcp_rcv_established: If the current TCP connection state is "ESTABLISHED", it processes the received packets and copies the data to the user space. If the packets are error-free, a fast process denominated "fast path" is executed, otherwise a "slow path" process is executed.

TCP Header Modifications
We used one of the TCP header reserved bits for the NACK implementation, as showed in Figure 3. If the NACK bit is "1", it means that a "corrupted" packet was received, otherwise it corresponds to an ACK. In the same way that ACK header, NACK header has a NACK information field and a NACK number. We used one of the TCP header reserved bits for the NACK implementation, as showed in Figure 3. If the NACK bit is "1", it means that a "corrupted" packet was received, otherwise it corresponds to an ACK. In the same way that ACK header, NACK header has a NACK information field and a NACK number. The code that defines the TCP header is in the /include/Linux/tcp.h file. Inside the tcphdr structure, we created the nack attribute for the NACK flag creation, and we reduced to three bits the attribute res1 that corresponds to the reserved TCP field. Algorithm 1 shows the tcp.h file modifications implemented.
Algorithm 1 tcphdr structure modifications for the NACK flag insertion res1 = 4 bits if little or big endian bitfield is used then The TCP flag position in the header is defined inside the tcp_flag_world structure with the TCP_FLAG_FLAGNAME = __cputobe32(0xXXXXXXXX) format, where "X" corresponds to the bit flag position. Hence, we added the TCP_FLAG_NACK = cpu_to_be32 (0x01000000) line in order to assign the NACK flag position in the TCP header.
Moreover, we added the #define TCPCB_FLAG_NACK 0x100 line inside the tcp_skb_cb structure in order to assign the value that NACK flag takes when it is assigned to a packet. Additionally, it was necessary to increase the flags attribute type from u8 (8 bits) to u16 (16 bits).

Sending NACK Notifications
We created and implemented the NACK sending function based on the tcp_send_ack function, located inside the /net/ipv4/tcp_output.c file, due to the similarity between NACK and ACK approach.  The code that defines the TCP header is in the /include/Linux/tcp.h file. Inside the tcphdr structure, we created the nack attribute for the NACK flag creation, and we reduced to three bits the attribute res1 that corresponds to the reserved TCP field. Algorithm 1 shows the tcp.h file modifications implemented.
The TCP flag position in the header is defined inside the tcp_flag_world structure with the TCP_FLAG_FLAGNAME = __cputobe32(0xXXXXXXXX) format, where "X" corresponds to the bit flag position. Hence, we added the TCP_FLAG_NACK = cpu_to_be32 (0x01000000) line in order to assign the NACK flag position in the TCP header.
Moreover, we added the #define TCPCB_FLAG_NACK 0x100 line inside the tcp_skb_cb structure in order to assign the value that NACK flag takes when it is assigned to a packet. Additionally, it was necessary to increase the flags attribute type from u8 (8 bits) to u16 (16 bits).

Sending NACK Notifications
We created and implemented the NACK sending function based on the tcp_send_ack function, located inside the /net/ipv4/tcp_output.c file, due to the similarity between NACK and ACK approach.

•
New tcp_send_nack function: This function, declared inside the /include/net/tcp.h file, sends NACK notifica-tions by four steps. First, it checks if the connection was restarted, if this is true, then the NACK notification is annulled. After that, it calls the skb_reserve function, that creates a socket buffer with a memory space of the maximum TCP header size. Then, the tcp_init_nondata_skb function sends the posi-tive NACK flag state and the sequence number to be retransmitted to the control buffer. Finally, the packet is transmitted to the network layer by the tcp_transmit_skb function. Algorithm 2 shows the description of the NACK sending function. The negative confirmations must be triggered by reception of the corrupted TCP packets, thus tcp_send_nack function is then called inside tcp_rcv_established function for detecting an error.

Receiving NACK Notifications
There are two possible paths for the received packets treatment, "Fast Path" and "Slow Path". All the packets with a raised NACK flag use the "Slow Path". First the packet integrity is checked by a checksum to consequently verify the NACK flag state, if this is positive, the tcp_retransmit_skb function is called for an immediate retransmission of the requested packet, which is determined by the tcp_write_queue_head function.

Results
We evaluated the proposed TCP-NACK protocol under different configuration environments and distances by using laptops with the modified TCP-NACK protocol under the Ubuntu kernel, and applying the necessary communication standards for each experiment. We choose to evaluate the general Quality of Service (QoS) provisioning parameters from a networking perspective using the θ , the delay, δ, and jitter metrics [18]. Hence, those parameters were obtained by the intrusive traffic technique, for which we employed the Distributed Internet Traffic Generator (D-ITG) software. D-ITG is a platform capable of producing IPv4 and IPv6 traffic, following stochastic models for packet size and inter departure time [19]. The details of our fulfilled experiments are described next.

Wireless Link Emulation
In this experiment, we evaluated TCP-NACK performance by the Network Emulator (Netem) software, which is an utility available within the Linux kernel from the 2.6.7 version, and allows emulating the link properties by specifying bandwidth parameters, δ, losses, and traffic control using statistical probability [20].
This experiment required a computer with the Ubuntu Operating System and with two network interfaces configured in bridge mode to emulate the wireless link. As user equipment, we employed two computers with the modified TCP-NACK Ubuntu Operating System, which acted as a client and a server, respectively. In each user equipment, we used the "Iperf" and "Tcpprobe" tools, available within the Linux repositories, those tools allowed to obtain the CWND and θ values.
The scenario consisted of two computers interconnected by an emulated wireless link, which was managed in an intermediate computer by the Netem software, as showed in Figure 4. The link emulation was required to maintain a fixed error rate for multiple traffic injections. employed two computers with the modified TCP-NACK Ubuntu Operating System, which acted as a client and a server, respectively. In each user equipment, we used the "Iperf" and "Tcpprobe" tools, available within the Linux repositories, those tools allowed to obtain the CWND and values.
The scenario consisted of two computers interconnected by an emulated wireless link, which was managed in an intermediate computer by the Netem software, as showed in Figure 4. The link emulation was required to maintain a fixed error rate for multiple traffic injections.  Netem is a utility available within the Linux kernel, it allows to emulate a communication link by the specification of its parameters [20]. Table 1 shows the parameters used for a 25-second emulation of the wireless link, with high packet errors probability, greater than 0.5% (P seg,TCP ≥ 5 × 10 −3 ). The commands used to define Netem parameters in the Linux terminal were: 1.
sudo tc qdisc add dev ethX parent 1:1 handle 10: netem corrupt Y% delay Z where ethX is the network interface name, Bandwidth is the link bandwidth in kb/s, Y is the error probability in percent, and Z is the δ in milliseconds.

Iperf and Tcpprobe Configuration
Iperf allowed to do a client-server TCP connection and to size its θ. Table 2 shows the necessary configuration commands for both user equipment. It usually runs in the emitter side with Tcpprobe tool, which allowed us to extract parameters as CWND, ssthresh and Congestion Avoidance threshold, and then to store the results in the data.out file.

θ Evaluation
We did tests with the Iperf tool to obtain the θ values under different error probabilities. Each test consisted in establishing a TCP connection and to perform a data transference for 1 minute.

CWND Evaluation
For the CWND evaluation, we started a TCP connection between both terminal equipment and transmitted the maximum possible raw bit rate through the emulated link for 25 seconds.

Short Distance Link Whit a Real-Time Video Game
We evaluated the TCP-NACK performance over a video gaming scenario with two players and one server wirelessly connected by an AP, where players and server were laptops with the modified TCP-NACK Ubuntu Operating System. The game at the server was "Quake IV" and the employed topology was Point-to-Multipoint (PtM), as Figure 5 shows.

Short Distance Link Whit a Real-Time Video Game
We evaluated the TCP-NACK performance over a video gaming scenario with two players and one server wirelessly connected by an AP, where players and server were laptops with the modified TCP-NACK Ubuntu Operating System. The game at the server was "Quake IV" and the employed topology was Point-to-Multipoint (PtM), as Figure 5 shows.  We perform this experiment over two scenarios. The first one was an in-door scenario with a 7-m distance between user equipment and the Netgear N600 wireless router configured as AP, using IEEE 802.11n as communication standard. The second one was an out-door scenario with 160 m' distance between the user equipment and the Ubiquiti PowerStation2 antenna configured as AP, using IEEE 802.11b/g as communication standard. The experiments were carried out with a 128.8 kb/s bandwidth between the user equipment and the server (uplink), and a 222 kb/s bandwidth between the server and the user equipment (downlink). Additionally, we introduced the OpenVPN tool for the adequacy of the multiplayer communication system. OpenVPN allows to connect multiple remote clients to the server, where any client can communicate with the rest of them [21].

Server Equipment Configuration
After the OpenVPN software was installed, we configured some parameters in the server.conf file with the data shown in Table 3.

User Equipment Configuration
At the user side of the network, we modified the client.conf file for the connectivity between equipment, with the parameters shown in Table 4 Additionally, we copied to the /etc/openvpn path, the user keys created at the server. After configuring the client and server, the clients executed the sudo./quake4-linux-1.4.2.x86.run command in a terminal, the command displayed the principal menu for the game, giving them the option to enter to the multiplayer mode. More details about this experiment are presented in [22].

Customer Premises Equipment (CPE). Both links used laptops with the modified TCP-NACK Ubuntu
Operating System as user equipment in a Point-to-Point (PtP) topology. Figure 6a shows the used WiFi link topology and Figure 6b shows the used WiMAX link topology. We performed tests under different bandwidth values by the modification of the number of packets per second and the frame size, as shown in Table 5 More details about this experiment are presented in [23].

Long Distance Scenario
For this experiment, we considered a 92 km PtP link with line-of-sight between the Crocker hill in Santa Cruz island (0°38′50.0′′S 90°19′21.0′′W) and San Joaquin tower in San Cristóbal island (0°53′26.9′′S 89°29′40.0′′W), using the IEEE 802.  WiMAX as communication standard, and employed 1, 2, 3 and 4 Mb/s bandwidth. First, we validated the link by simulation through the "SImulation of Radio-Electric NETworks" (SIRENET) software and the Motorola PTP LINKPlanner software, with the aim of eliminating most design assumptions. Eventually, we used two parabolic antennas with 24 dBi gain, two computers with the TCP-NACK modified kernel, and the Motorola PTP 58,600 proprietary radio equipment to implement the network. Figure 7 shows the PtP topology used for this experiment. More details about this experiment are presented in [24].

Discussion
Several tests were executed in each experiment scenario with the aim of obtaining average results. We obtained, from emulation experiment, values by the computation of the area under the CWND performance curve. Likewise, we obtained from field experiments, , δ, and jitter values by D-ITG software.

Results from Mathematical Analysis
A normalized throughput (η ̅ ) was obtained for TCP Reno, TCP Westwood, TCP-NACK Reno and TCP-NACK Westwood. The TCP Reno and Westwood results were calculated by (16), and the We performed tests under different bandwidth values by the modification of the number of packets per second and the frame size, as shown in Table 5 More details about this experiment are presented in [23].

Long Distance Scenario
For this experiment, we considered a 92 km PtP link with line-of-sight between the Crocker hill in Santa Cruz island (0 • 38 50.0 S 90 • 19 21.0 W) and San Joaquin tower in San Cristóbal island (0 • 53 26.9 S 89 • 29 40.0 W), using the IEEE 802.  WiMAX as communication standard, and employed 1, 2, 3 and 4 Mb/s bandwidth. First, we validated the link by simulation through the "SImulation of Radio-Electric NETworks" (SIRENET) software and the Motorola PTP LINKPlanner software, with the aim of eliminating most design assumptions. Eventually, we used two parabolic antennas with 24 dBi gain, two computers with the TCP-NACK modified kernel, and the Motorola PTP 58,600 proprietary radio equipment to implement the network. Figure 7 shows the PtP topology used for this experiment. More details about this experiment are presented in [24]. We performed tests under different bandwidth values by the modification of the number of packets per second and the frame size, as shown in Table 5 More details about this experiment are presented in [23].

Long Distance Scenario
For this experiment, we considered a 92 km PtP link with line-of-sight between the Crocker hill in Santa Cruz island (0°38′50.0′′S 90°19′21.0′′W) and San Joaquin tower in San Cristóbal island (0°53′26.9′′S 89°29′40.0′′W), using the IEEE 802.  WiMAX as communication standard, and employed 1, 2, 3 and 4 Mb/s bandwidth. First, we validated the link by simulation through the "SImulation of Radio-Electric NETworks" (SIRENET) software and the Motorola PTP LINKPlanner software, with the aim of eliminating most design assumptions. Eventually, we used two parabolic antennas with 24 dBi gain, two computers with the TCP-NACK modified kernel, and the Motorola PTP 58,600 proprietary radio equipment to implement the network. Figure 7 shows the PtP topology used for this experiment. More details about this experiment are presented in [24].

Discussion
Several tests were executed in each experiment scenario with the aim of obtaining average results. We obtained, from emulation experiment, values by the computation of the area under the CWND performance curve. Likewise, we obtained from field experiments, , δ, and jitter values by D-ITG software.

Results from Mathematical Analysis
A normalized throughput (η ̅ ) was obtained for TCP Reno, TCP Westwood, TCP-NACK Reno and TCP-NACK Westwood. The TCP Reno and Westwood results were calculated by (16), and the

Discussion
Several tests were executed in each experiment scenario with the aim of obtaining average results. We obtained, from emulation experiment, θ values by the computation of the area under the CWND performance curve. Likewise, we obtained from field experiments, θ , δ, and jitter values by D-ITG software.

Results from Mathematical Analysis
A normalized throughput (ηϑ) was obtained for TCP Reno, TCP Westwood, TCP-NACK Reno and TCP-NACK Westwood. The TCP Reno and Westwood results were calculated by (16), and the TCP-NACK results by (17). Figure 8 shows a comparison of the generated curves for each protocol as a function of the error packet probability. We found that both TCP-NACK versions had a similar behavior among them, and a better performance that its generic versions. Therefore, based on this analysis, for the next experiments, we only compare TCP-NACK with TCP Reno, declared as Generic TCP.
Future Internet 2020, 12, x FOR PEER REVIEW 12 of 17 TCP-NACK results by (17). Figure 8 shows a comparison of the generated curves for each protocol as a function of the error packet probability. We found that both TCP-NACK versions had a similar behavior among them, and a better performance that its generic versions. Therefore, based on this analysis, for the next experiments, we only compare TCP-NACK with TCP Reno, declared as Generic TCP.

Results from Emulation Experiment
For this experiment, we obtained a η ̅ comparison between Generic TCP and TCP-NACK as a function of the error packet probability. Figure 9 shows the generated curves for each emulated protocol. We obtained the CWND size as a function of the BER value through time and calculated the area under each CWND curve. Hence, we obtained the ̅ values shown in Table 6. We found that the CWND size of TCP-NACK surpass the CWND size of Generic TCP in 2 average packets, leading to a higher area under the curve, or a ̅ increment. The throughput of the TCP-NACK was better than TCP-Reno and if we compare the results presented in Figure 8, the throughput of the TCP-NACK also appear better than TCP-Westwood, and the algorithm of the TCP-NACK has less complexity than TCP-Westwood. Therefore, TCP-NACK will be used in practical experiments to validate its performance.

Results from Emulation Experiment
For this experiment, we obtained a ηϑ comparison between Generic TCP and TCP-NACK as a function of the error packet probability. Figure 9 shows the generated curves for each emulated protocol. We obtained the CWND size as a function of the BER value through time and calculated the area under each CWND curve. Hence, we obtained the θ values shown in Table 6. We found that the CWND size of TCP-NACK surpass the CWND size of Generic TCP in 2 average packets, leading to a higher area under the curve, or a θ increment. The throughput of the TCP-NACK was better than TCP-Reno and if we compare the results presented in Figure 8, the throughput of the TCP-NACK also appear better than TCP-Westwood, and the algorithm of the TCP-NACK has less complexity than TCP-Westwood. Therefore, TCP-NACK will be used in practical experiments to validate its performance.
Future Internet 2020, 12, x FOR PEER REVIEW 12 of 17 TCP-NACK results by (17). Figure 8 shows a comparison of the generated curves for each protocol as a function of the error packet probability. We found that both TCP-NACK versions had a similar behavior among them, and a better performance that its generic versions. Therefore, based on this analysis, for the next experiments, we only compare TCP-NACK with TCP Reno, declared as Generic TCP.

Results from Emulation Experiment
For this experiment, we obtained a η ̅ comparison between Generic TCP and TCP-NACK as a function of the error packet probability. Figure 9 shows the generated curves for each emulated protocol. We obtained the CWND size as a function of the BER value through time and calculated the area under each CWND curve. Hence, we obtained the ̅ values shown in Table 6. We found that the CWND size of TCP-NACK surpass the CWND size of Generic TCP in 2 average packets, leading to a higher area under the curve, or a ̅ increment. The throughput of the TCP-NACK was better than TCP-Reno and if we compare the results presented in Figure 8, the throughput of the TCP-NACK also appear better than TCP-Westwood, and the algorithm of the TCP-NACK has less complexity than TCP-Westwood. Therefore, TCP-NACK will be used in practical experiments to validate its performance.

Results from Indoor Short Distance Experiment
For this experiment by using WiFi technology in indoor scenarios, we obtained θ, δ, and jitter as a function of the distance and the traffic direction (uplink or downlink). Figure 10 shows the performance results obtained by using the D-ITG software. The results show a lower θ performance for TCP-NACK, but a better δ and jitter performance when compared to Generic TCP.

Results from Indoor Short Distance Experiment
For this experiment by using WiFi technology in indoor scenarios, we obtained ̅ , δ, and jitter as a function of the distance and the traffic direction (uplink or downlink). Figure 10 shows the performance results obtained by using the D-ITG software. The results show a lower ̅ performance for TCP-NACK, but a better δ and jitter performance when compared to Generic TCP.

Results from Outdoor Short-Medium Distance Experiment
For this experiment in outdoor scenarios, we obtained ̅ , δ, and jitter as a function of the distance and bandwidth, therefore we decidedto represent the obtained results as 3D surfaces, as Figure 11 shows. Figure 11a, Figure 11c, and Figure 11e show the ̅ , δ, and jitter results, respectively. Hence, in order to show whichprotocol has a better performance, Figure 11b corresponds to atop view of Figure 11a, Figure 11d corresponds to a bottom view of Figure 11c, and Figure 11f corresponds to a bottom view of Figure 11e, the better protocol corresponds to the one that encloses a long area. Additionally, the left side of the yellow surface in all the subfigures inside Figure 11 corresponds to outdoor scenarios with short distances (to 300 m) by using WiFi Technology, and the right side to medium distances (from 300 m to 826 m) by using WiMAX technology. Figure 11b, Figure 11d, and Figure 11f suggest that TCP-NACK has best performance than the Generic TCP in the majority of the cases. We observed that TCP-NACK had a better performance in terms of

Results from Outdoor Short-Medium Distance Experiment
For this experiment in outdoor scenarios, we obtained θ, δ, and jitter as a function of the distance and bandwidth, therefore we decided to represent the obtained results as 3D surfaces, as Figure 11 shows. Figure 11a,c,e show the θ, δ, and jitter results, respectively. Hence, in order to show which protocol has a better performance, Figure 11b corresponds to a top view of Figure 11a, Figure 11d corresponds to a bottom view of Figure 11c, and Figure 11f corresponds to a bottom view of Figure 11e, the better protocol corresponds to the one that encloses a long area. Additionally, the left side of the yellow surface in all the subfigures inside Figure 11 corresponds to outdoor scenarios with short distances (to 300 m) by using WiFi Technology, and the right side to medium distances (from 300 m to 826 m) by using WiMAX technology. Figure 11b,d,f suggest that TCP-NACK has best performance than the Generic TCP in the majority of the cases. We observed that TCP-NACK had a better performance in terms of throughput, delay and jitter. We found that the algorithm TCP-NACK, by not decreasing the congestion window, as we could observe in Figure 11, for WiFi technology TCP-NACK in mean has offer an improvement over the 70% in terms of throughput, delay and jitter, meanwhile for WiMAX technology over the 70% for throughput and jitter, and almost 100% in terms of delay.

Results from Long Distance Experiment
For this experiment, we obtained ̅ , δ, and jitter as a function of the bandwidth for a 94 km distance between terminals. Figure 12 shows ̅ , δ, and jitter results obtained by using the D-ITG software. The results show that there are low ̅ and jitter variance between TCP-NACK and Generic TCP, but a better δ performance for TCP-NACK for bandwidth up to 3000 kbps.

Results from Long Distance Experiment
For this experiment, we obtained θ, δ, and jitter as a function of the bandwidth for a 94 km distance between terminals. Figure 12 shows θ, δ, and jitter results obtained by using the D-ITG software. The results show that there are low θ and jitter variance between TCP-NACK and Generic TCP, but a better δ performance for TCP-NACK for bandwidth up to 3000 kbps. We determined that this was not improved in terms of throughput and jitter, but in terms of delay, we observed a significantly reduction; this is due to the fact that we considered to modify the ACK timeout value for MAC layer in order to reach long distance [24], but we did not consider changing the main parameters related to ACK timeout at Transport layer as this is out of this study's scope.

Conclusion and Future Work
Since the TCP protocol was designed to work in wired networks, its performance is not adequate for wireless networks, where the packets corrupted for interference, obstacles or fading are discarded and taken as a fictional congestion con-sequence. This assumption entails to an unnecessary CWND reduction which decreases the transmission bit rate.
In this paper, we proposed a TCP-NACK protocol that endures wireless performance problems by the incorporation of an error notification or "NACK" to the Generic TCP protocol functionality. This notification indicates to the transmitter the arrival of corrupted packets, proceeding to an immediate re-transmission without the CWND reduction. For its validation, we exposed the mathematical analysis, configurations to the Linux source code, emulation, and the testbed analysis in real scenarios.
The results obtained demonstrate a better performance of TCP-NACK protocol against its generic counterpart (TCP Reno) under different scenarios including different distances, bandwidths, packet error rates and technologies employed. Regardless of the fact that the experimental results obtained are lower than the mathematical results, we achieved an average improvement of 54% in ̅ , 26% in δ, and 5% in jitter when compared to Generic TCP. It is important to highlight that we obtained the best ̅ results between 100 and 414 meters, where, on average, there is an improvement of 90%. The principal differences among our work and those described in the literature are the We determined that this was not improved in terms of throughput and jitter, but in terms of delay, we observed a significantly reduction; this is due to the fact that we considered to modify the ACK timeout value for MAC layer in order to reach long distance [24], but we did not consider changing the main parameters related to ACK timeout at Transport layer as this is out of this study's scope.

Conclusion and Future Work
Since the TCP protocol was designed to work in wired networks, its performance is not adequate for wireless networks, where the packets corrupted for interference, obstacles or fading are discarded and taken as a fictional congestion con-sequence. This assumption entails to an unnecessary CWND reduction which decreases the transmission bit rate.
In this paper, we proposed a TCP-NACK protocol that endures wireless performance problems by the incorporation of an error notification or "NACK" to the Generic TCP protocol functionality. This notification indicates to the transmitter the arrival of corrupted packets, proceeding to an immediate re-transmission without the CWND reduction. For its validation, we exposed the mathematical analysis, configurations to the Linux source code, emulation, and the testbed analysis in real scenarios.
The results obtained demonstrate a better performance of TCP-NACK protocol against its generic counterpart (TCP Reno) under different scenarios including different distances, bandwidths, packet error rates and technologies employed. Regardless of the fact that the experimental results obtained are lower than the mathematical results, we achieved an average improvement of 54% in θ, 26% in δ, and 5% in jitter when compared to Generic TCP. It is important to highlight that we obtained the best θ results between 100 and 414 m, where, on average, there is an improvement of 90%. The principal differences among our work and those described in the literature are the performance evaluation as a function of the distance, and the experimentation tests over networks with exclusively wireless links.
In summary, TCP-NACK is a good option for wireless networks, and it is perfectly attachable to any personal computer as a modified Linux operating system. This proposal was evaluated under several real conditions and demonstrated high improvements when compared with TCP Reno protocol.
As future works we are interested in considering the communication standard, frequency and the running application (e.g., VoIP) as variables. We are also interested in performing tests with larger distances and bandwidths evenly distributed. We are also planning to include tests with an optimization of the RTT calculation, by applying the mathematical modeling described in [24] with the aim of improving the θ values for wireless links with short and long distances. Finally, we are interested in comparing with other proposals which are available to be implemented in open hardware.