The purpose of this sub-section is to sort UDP control information in two parts: critical (sensitive) and non-critical for the communication procedure. This part focuses on UDP header and the impact of undetected errors in the header part of its segment. Figure 1 illustrates the different fields which appear in a UDP packet. The first step is to discriminate between critical (sensitive) control information for successful communication and those that are not.

Sensitive control information:

Below is a list of UDP header fields that we consider to be sensitive information for transport layer transmission:

Let us describe briefly the importance of these critical parameters. We start with the Destination port number. The destination port number is a critical parameter because an error in this field will result in the data either being delivered to the wrong process or the process not being able to exist. The process doesn’t exist in other words, it is as if the data is lost. The fact that the data can be delivered to a wrong process makes this field a very important one to protect. Concerning the source port number, it is also important as it corresponds to the sender’s address, which is useful when sending back replies. Finally, the Checksum field is for important usage because it helps to perform the error detection functionality of the UDP protocol. Therefore, we can imagine that improving its reliability will improve the performance of the error-detection step. What can we say about non-sensitive control information?

Non-sensitive control information of UDP:

In this sub-section we are going to talk about UDP header fields that we consider to be non-sensitive with regard to communication between processes while explaining the reason of our choice. The field that we consider as non-sensitive is the Length field. The Length field data determines the length of the segment but if we use a principle similar to TCP by setting a MSS (Maximum Segment Size) then this field becomes useless and therefore it can be used for encoding. In this paper, we are making the suggestion to set a maximum size for UDP and then used the Length field for encoding. If fact, if the stream of bits to be sent is of size M bits, then we will have $n=\lfloor M/MSS\rfloor$ segments ( $\lfloor y\rfloor$ represents the integer part of y) and the last segment will have a size equal to $n1=M-n\times MSS<MSS$ bits therefore we propose using 2 bits (for example the first two bits) of the Length field to distinguish between the $n$ packets of size MSS and the only packet of size $n1<MSS$. This last packet can be handled by using the remaining bits of the Length field to specify its length. This means that this last packet will be processed as what normally happens in UDP. As the two first bits are concerned an example of possible assignment is given by:

In this paper, we will not care about the case where the size is less than MSS since the manner of dealing with that is straightforward. We plan to use this field for coding and we do not plan to protect non-sensitive control information with a coding. However, one must derive from this work an algorithm that also includes this field. Table 1 summarizes the classification and assumption we are using for the rest of the paper. In this table “not-used” means that we will use this field for encoding. Having identified the critical fields in the header part of UDP, the next step is to improve their reliability.

This sub-section deals with the algorithm that we propose in order to encode source and destination port numbers as well as the checksum. We assume that a principle similar to MSS in TCP is used, therefore the Length field will be used for encoding process. Moreover by analysis users’ habits, we realized that a great portion of users will not have at the same time more than 4 or 16 TCP and UDP sockets open at the same time. That is why we suggest re-scaling the bits used for source and destination port numbers in an adaptive way. As an illustration, we choose to use 4 states:

In order to distinguish these four states, we need 2 bits, which can be taken from the Length field (let us used the two last bits). An example is given in Table 2 :

However, since states are linked to the fact that 00 are the two first bits of the Length field, we suggest combining bits of states and bits to distinguish size (either less or equal than MSS) by 5 Cases where we use 6 bits (of the Length field) to discriminate between then as described by Table 3 . The assignment of bits is done in order for any two sequences of 6 bits to differ by at least 3 bits. That is, the Hamming distance is at least 3. This will add robustness on the transmitted sequence since 3 bits difference provides a self-ability to correct 1 bit error at the receiving side. It means that 10 bits will remain for the encoding procedure. The six bits will be sent by both parts of the communication to reflect their current state in a similar manner as information is carried by the window field in TCP header for flow control. Any change in one part will be reported to the other part so that both sides move to the same state throughout the communication. The part with the higher number of opened sockets determines the state of the communication.

When a state $i$ is used it leaves a given amount of bits (as the number of bits of the port number is concerned ) that are not used and this amount of bits adds to the remaining 10 bits of the Length field to give the total number of bits which are available for the encoding procedure. Table 4 gives the details of what we obtain from each state while providing the coding rate of each state. Remember that the data to be encoded are the port numbers and the checksum.

Then an appropriate coding scheme such convolutional codes, turbo codes, linear block codes [8] [9] can be used. It is worth mentioning that the scaling of the port numbers in states can be modified in many ways. That is instead of 4 states we can decide to have 8 states and so forth. After presenting the UDP protocol and our method to improve the reliability of its critical control data, let us focus on TCP.

This sub-section aims to sort TCP control information in two parts: critical (sensitive) and non-critical for reliability procedure. It focuses on TCP header and the impact of undetected errors in the header part of its segment. Figure 2 illustrates the different fields which appear in a TCP packet. As in the previous section, the first step is to discriminate between critical (sensitive) control information for reliable process and those which are not.

Sensitive control information:

Below is a list of TCP header fields that we consider to be sensitive information for reliable procedure:

Let us describe briefly the importance of these critical parameters. Here, the Source port number, the Destination port number, the Checksum fields have almost the same purpose as in UDP. One thing that we can add is to stress the importance of the Checksum field which performance impacts the reliability of TCP. Therefore is very critical here. Talking about the Sequence number field, we can say that this field is critical in the sense that if helps to site the receive data in the flow of information, any undetected error in this field means that the flow of information may be altered or the data will be discarded if error leads to a smaller sequence number than the one expected. Finally the bits ACK, RST, SYN, FIN are critical since they concern the management of the communication process. Let us look at non-sensitive control information.

Non-sensitive control information:

In this sub-section, we are going to talk about TCP header fields that we consider to be non-sensitive with regard to reliability and we will explain the reason of our choice. One field that, we consider as non-sensitive is the window one. The window’s data is important for flow control but we choose to consider it as non-critical information for the good functioning of the reliable protocol. Indeed an error in this field will not be harmful for the reliable process, it will influence mostly the flow control procedure. Moreover, this error can be alleviated by subsequent transmissions which can provide error-free information. Another non-critical field for reliability is the acknowledgment number field. Again, the acknowledgment number field determines the way the information will be sent back by the recipient. However, the acknowledgment number is not consider as a critical parameter since TCP used cumulative acknowledgment, an error in this field will not be harmful for the functioning of the reliability process. Indeed, subsequent packets with correct acknowledgment number field will restore the information sent or needed. In addition to these non-sensitive information, we consider in this paper that the bits PSH, URG are not used and that throughout the transmission the size of the header field remains constant i.e. 20 bytes. As for UDP, we do not plan to protect non-sensitive control information with a coding. However one can derive from this work an algorithm which may include some of these bits or fields. Table 5 summarizes the classification and assumption we are using for the rest of the paper. Having identified the critical fields in the header part of TCP the next step is to improve their reliability.

This section deals with the algorithm we are suggesting. The idea is to encode the sensitive data of TCP header. We also make use of habits of users when they go to the Internet as mentioned earlier in section 2. Based on this observation we decide to rescale the number of bits use for source port number and destination port number in the same way as for UDP (see section 2). The bits of the PSH and URG are used for coding. Remember that the data that we are encoding are: source port number, destination port number, sequence number, RST, SYN, FIN, ACK and checksum. To distinguish between the four states we suggest in this case to use 5 bits sequences with a minimum Hamming distance of 3 as presented in Table 6

From this table, we have derived Table 7 , which gives the details of what we obtain from each state while providing the coding rate of each state. Let us make the remark that a possibility of including the checksum in the decoding process may exist since a first decoding provides the checksum result. Then, any error detected by the checksum can be used again in a second decoding process in order to improve the reliability of bits (principle similar to turbo code). This procedure could have the effect similar to having smaller code rate.

Let us sum up the method which captures the proposed algorithm.

METHODOLOGY:

1) Discriminate between sensitive and non-sensitive control data

2) Select amongst the non-sensitive control data those which are usually not-used or which functionalities can be handled by another mechanism (example Length field replaced by MSS)

3) Use the fields selected in 2. to code sensitive fields.

Having presented the algorithm we are using to encode some control data in TCP and UDP header let us see which potential gain we can have with such code rate.