A standard IEEE 802.11 device follows the seven-layered OSI Model, thus we must overrule any cross-layer assumptions and settle with the aspect that layer functions and elements are not specified and should be transparent to other layers. The only information that the MAC layer receives from the upper layer, except the actual payload, is the Type of Service (ToS). So, aa a provisional idea will be to exclude the use of DCA from BE flows since large portion of these application utilize the TCP protocol. Then, similar with TCP-Aware, this can be easily implemented by just placing the DCA process into a conditional statement which will intermittently check if the incoming packets are of BE type. Then again, sometimes there are BE flows that are using UDP connections and other real- time applications (AC V I or AC V O) that are connected trough TCP links. Therefore, this approach may not be realistic either.
Recent research on Internet traffic classification algorithms has yielded a flurry of proposed approaches for distinguishing types of traffic based on transport layer ports, host behaviour, and flow features [153]. Traditional methods of traffic flow classification relied on the well-known ports registered with Internet Assigned Numbers Authority (IANA) to represent a specific application. However, emerg- ing popular application such as those that support P2P file sharing, started to use arbitrary port numbers in order to hide their identity, so solely based on port numbers alone could lead to inaccurate assumptions [154, 155, 156]. An-
other more reliable approach is deep packet inspection, a work-around that was mainly used by commercial tools [157, 158] which inspect packet payloads for specific string patterns of known applications [159, 160, 161, 162], provided that the packets are not encrypted. Nevertheless, it is costly, processor and bandwidth resource-thirsty and causes tremendous privacy and legal concerns. Two proposed traffic classification approaches that avoid payload inspection and tend to be more popular are: i) host-behaviour-based, which takes advantage of information re- garding “social interaction” of hosts [163, 155, 159], and ii) flow features-based, which classifies based on flow duration, number and size of packets per flow, and inter-packet arrival time [164, 165, 166, 167, 168, 169].
Taking in consideration the aforementioned traffic classification algorithms, we came to the conclusion that the approach with the most prospects is the flow feature-based. So, in order to come up with a potential resolution, we had to identify a pattern for the TCP flows using the three (3) types of classification: a) flow duration, b) number and size of packets per flow, and c) inter-packet arrival time. The inter-packet arrival time was identified from the trace files collected from various OPNET simulations. The traces showed that the TCP segments, assigned in a single queue buffer, were arriving at the MAC layer in a homogeneous Poison process with a constant rate. The period from the point where the first segment arrived at the MAC layer until a second full segment appeared, from the same TCP process, was observed to be precisely 10 µs. In addition, we found that most of the TCP segments complied with the MSS and MTU rules, so we were able to determine the expected packet (segment) length of the payload arriving from the higher layers. Figure 7.4 illustrates the encapsulation method that occurs over each layer with the additional headers and tails. Therefore, for a segment size equal to 1, 460 bytes and following the encapsulation process, the packet that will arrive to the MAC layer will be including a TCP header of 20 bytes, consequently will have a total size of 1, 480 bytes. Also, packets smaller than 44 bytes are mostly TCP’s associated packets, such as ACK, SYN, FIN or RST. Last but not least, TCP flows start with a three-way handshake and terminate with a four-way handshake (or a time-out), so we can identify a signature for the flow duration. In conclusion, all these clues are the foundations to design a cognitive agent that will select the incoming flows.
Figure 7.4: Encapsulation Process
The new proposed enhanced DCA method is called SDCA and is fundamen- tally based on the TCP-Aware with only difference the conditional decisions of determine the type of flow. The new algorithm will try to distinguish the flows by observing its features. So, each AC buffer collects discrete information for each recipient and reviews the flows separately. Within the function there is a constant variable which defines the level of tolerance, meaning that there could be a margin of deviation on the TCP packet rate. In order to decrease the level of misconception, the function also checks the packet sizes. It is known that when a TCP connection establishes there is a three-way handshake, a negotiation be- tween the two nodes where they shared information with specific segments with no data but just the headers. The size of these segments can easily be determined (40 – 44 bytes long) and audited at the beginning and end of the transaction. As a result, whenever a packet shows up at the MAC with length less than 44 bytes then the function increases its level of awareness.
The accuracy of the function’s decisions has been tested with a set of traffic patterns and found that if there are any misjudgements on the flow type, there won’t be any negative development over the SDCA performance. Let us assume an example where both UDP and TCP belong in the same AC and share the same receiver. Then, the function may not be able to distinguish any distinct- ness between them two as the next TCP packet will be compared with the last arrived UDP traffic, or vice versa. Nevertheless, the packets in queue increases exponentially and DCA triggers before the interlock situation discussed earlier
occurs. Also, it is unusual to receive UDP traffic with a 10 µs inter-arrival rate and in a series of TCP packets, it will definitely have at least two consequent TCP packets. So, once the first packet initiates a transmission sequence, every other following packet (UDP or TCP) that arrives during that time will be trans- mitted too. Finally, because the nature of TCP traffic is generally BE flows, it will ordinarily have a long AIFS and Back Off timer so it helps the aggregates to increase further without the need of SDCA.