IV.

Implementation and tests

1. Linux implementation
To use the TCP-NACK protocol in a physical machine is necessary to modify the TCP/IP
protocol stack from the Linux kernel source code, specifically the include and net
directories source code, which are distributed as is show in figure 4.

a. Sockets implementation
In Linux, the different communication protocols are implemented by sockets, which
works as a common interface between the user and the different files systems and
device systems. There are three data structures for the sockets handling. The first is
denominated socket buffer, which store the packet information, the second is
denominated socket, which register the open connections, and the last is
denominated sock, which maintains the open connections state {12}.

b. Data sending by TCP

TCP is a protocol that ensure the reliable transmission executing a data flow
management. There are three principal functions that intervene in the data sending
process and flow management by TCP inside the Linux kernel.

1) tcp_sendmsg: Copies the user space data to the Linux kernel space where are
assigned to the socket buffers and divide it in smaller segments.
2) tcp_send_skb: Organizes the data in 'socket buffers' to the transmission queue
and decides whether the transmission can take place or not.
3) Tcp_transmit_skb: Builds the TCP header and sends the segments to the network
layer.

c. Data reception by TCP

The received packets must be transferred from the network layer to the transport
layer by the next functions for the TCP header processing and the data processing in
the segment.

1) Tcp_v4_rcv: Verifies the packet integrity, checks that the packet is destined to that
computer, process the transport layer checksum and removes the IP header.
2) Tcp_v4_do_rcv: Verifies that the received segment has a complete header and
checks the current TCP connection state.
3) Tcp_rcv_established: If the current TCP connection is defined as ESTABLISHED,
processes the received segments and copies the data to the user space. If the
segments havent errors a fast process is executed denominated fast path,
otherwise slow path is executed.

d. TCP-NACK Linux implementation

Below are detailed the Linux kernel code modifications in his 2.6.32 version. Those
modifications must be compiled and installed as a new kernel, as is explained in {15}.
 TCP header modification
The code that defines the TCP header is located in /include/Linux/tcp.h. For the
NACK flag creation, we created a new attribute nack reducing to three bits the
attribute res1 that corresponds to the reserved TCP field, as is show in Code 4.

In Code 4 we assigned the space for a TCP notification flag. To assign his value and
definition we modified the code inside the tcp_flag_world structure, as is show in
Code 5.

Finally, inside the tcp_skb_cb structure, is necessary to assign the value that the
NACK flag takes when is assigned to a segment, creating the #define
TCPCB_FLAG_NACK 0x100 line, as is show in Code 6. Also is necessary to enlarge
the flags attribute type from u8 (8 bits) to u16 (16 bits).

Sending NACK error notifications

Due to the similarity between NACK and ACK notifications, the NACKs sending
function was implemented based on the tcp_send_ack function, which is located
in /net/ipv4/tcp_output.c.

- New tcp_send_nack function

This function that we declared in /include/net/tcp.h do the NACKs
notification sending by fourth steps. First is checked if the connection was
restarted, checking the TCP connection state, if its true then the NACK
notification isnt sent. Then the skb_reserve function is invoked, that creates
a socket buffer with a memory space corresponding to the maximum TCP
header size. Later by the tcp_init_nondata_skb function is send to the
control buffer the positive state for the NACK flag and the sequence number
to be retransmitted. Finally with the tcp_transmit_skb function the segment
is transmitted to the network layer. All this structure is show in Code 7.

- tcp_transmit_skb modification
If the segment to be transmitted has raised the new TCP_FLAG_NACK flag,
the TCP confirmation number field must contain the sequence number of the
detected damaged segment. This modification is show in Code 8.

The negative confirmations must be generated after to receive defected TCP

segments, thus the function in charge to transmit a NACK segment
tcp_send_nack is invoked in the tcp_rcv_established function after to
detect an error, as is show in Code 9.

Error notifications reception NACK

Inside the received segments treatment there are two possible paths, Fast Path
and Slow Path, all the segments with a raised NACK flag employ Slow Path. First
is checked the segment integrity by a checksum to consequently verify the NACK
 flag state. If it's positive, is invoked the tcp_retransmit_skb function for a
requested segment immediate retransmission, which is determined by the
tcp_write_queue_head function. This modification is shown in Code 10.

All this configuration is more detail explained in {15}.

2. Field tests
Once the Linux kernel that works with the TCP-NACK protocol was created, is possible to
do more realistic tests. In those tests intervene emulation experiments, different distance
links, different environments performance, different injected bit rate and the use of WiFi
and WiMAX technologies.

a. Wireless link emulation

This scenario consists of 2 computers connected by an emulated wireless link by the
Netem software, which it's installed in a third intermediate computer whit two
network interfaces configured in bridge mode, as is show in Figure 5. The link's
emulation is because the necessity to maintain a fixed error rate for multiple traffic
inyections {15}.

Netem is a utility available in the Linux kernel. Allows to emulate a link by specifying
bandwidth, delay, losses and traffic control {14}. The emulated wireless link contains
the described parameters in Table 1.

The command used to define the Netems parameters in the Linux terminal are the
next:

1) sudo tc qdisc add dev ethX root handle 1:0 tbf rate Bandwidthkbit
2) sudo tc qdisc add dev ethX parent 1:1 handle 10: netem corrupt Y% delay Z

Where ethX is the network interface name, Bandwidthkbit is the links bandwidth in
kbps, Y is the error probability in percent and Z is the delay in milliseconds.

Iperf configuration
Iperf allows to do a client-server TCP connection and size its transference data
rate {15}. In Table 2 are detailed the necessary configuration commands by
terminal for both terminal equipment.

Throughput evaluation
We did tests with the Iperf tool to obtain the average transference data rate
under the different error probabilities. Each essay consisted in establish a TCP
connection and do a data transference while one minute.

CWND evaluation
 For this evaluation we started a TCP connection between the terminal equipment,
and while 25 seconds we transmitted the maximum possible data through the
emulated link.

This is more detail explained in {15}.

b. Short distance scenario whit real time games.

In the present experiment we did the evaluation of the new TCP-NACK protocol over a
gaming scenario where are two players and a server wirelessly connected. The
employed topology is Point-to-Multipoint, as is show in Figure 6.

Is introduced in the system the OpenVPN tool, which uses a TUN interphase that is a
network layer emulation. OpenVNP allows to connect multiple remote clients to a
server where anyone client can communicate whit the rest {17}.

Server equipment configuration

Once the OpenVNP software is installed, we configured some parameters
modifying the server.conf file with the data showed in Table 3.

User equipment configuration

In the user case, the file to modify is client.conf, which parameters are
established according Table 4. Also is necessary to copy to the direction
/etc/openvnp the user keys created at the server.

Once configured client and server, the client execute in a terminal the
sudo./quake4-linux-1.4.2.x86.run command. The command displays the game
principal menu as is show in Figure 7, giving us the option of enter to the
multiplayer mode.

The evaluated parameters are throughput, delay and jitter by the D-ITG tool. This
is more detail explained in {17}.

c. Short and medium distance scenario.

For this experiment, we did tests in different distances, environments and
communication standards,