Network traffic characteristics and TCP protocol evolution analysis

Evolution Over Time of Network Parameters

In this chapter, we present the definitions and background material on the topics covered in this thesis along with the relevant literature survey. In network environment, traffic analysis must be carried out in ongoing bases in order to account for surfacing applications, there effort on traffic, and their possible control. Some analyses are extensive, but most entities opt for monitoring and alarms alerting them when malicious applications have entered the network. Form General Interne traffic analysis, studies have shown that even though, many emerging application take advantage of non-connected oriented transfer mechanisms like the one offered by the User Datagram Protocol (UDP); the TCP is the dominant transmission protocol in terms of byte load. Thus, many studies concentrate on it and the applications transmitting over it.

User connectivity to computer networks and the Internet has increased dramatically in the past couple of decades. The appeals of being able to access information and share resources from geographically dispersed location have led to the proliferation of computer networks and the continuity increasing demands of network capacity. At their beginning, computer networks were composed of only a few general purpose nodes. Then they grew to bulletin boards, implementation into educational institutions, business community, organizations and individual users having multiple device networks at home (Developments in Networking Technologies). It is fair to say that networking has become an integral part of all computer systems. Any effort in the upgrade or expansion of computer systems must consider the network as well. Many organizations take the seat-of-the-pants approach in planning for their network systems and capacity upgrades.

During the past years the number of internet users grew extensively. In 2005, the percentage of Internet users has increased to 15.7 and by June 2008, 21.9% of the world's population had access to the Internet (Miniwatts Marketing Group, 2008). In the year 2008, the geographical regions with the largest population percentage of internet users were North America, Oceania/Australia, and Europe (Miniwatts Marketing Group, 2008).

To help in the expansion or upgrade planning, networks are often monitored and data are collected for analysis and projection. Due to the size of computer networks and overwhelming amount of data exchanged between them, monitoring, collecting and analyzing network flow data is an enormous task. Network traffic studies have attempted to model network traffic after distributions with constant arrival rates and have failed (Paxson and Floyd, 1995). Other studies have explored the characteristics of network traffic with respect to flows and their effect on network traffic (Kim, 2004).

TCP has been the dominant transport protocol in the Internet for decades. Consequently, the performance of the Internet is influenced by TCP significantly. The recent TCP standard, TCP Reno (46), is a marking/loss-based system. In this type of schemes, packet loss or packet marking in the shape f Explicit Congestion Notification (ECN) feedback offered by Active Queue Management in routers amongst a source and a destination are utilized as pointers of network congestion (59). TCP Reno necessarily does have a probing phase and a decreasing phase. The probing phase of standard TCP contains an exponential on the increase phase and of a linear increasing phase. Throughout the slow-start phase, the window size will be twice every Round Trip Time (RTT), i.e., augment the window size exponentially. The probing phase ends when overcrowding is practiced in the form of ECN, 3 replacement acknowledgements or a break. At the moment TCP Reno put into practice a multiplicative decrease behavior. The TCP Reno location of the congestion window throughout the congestion evasion phase is: on ACK welcome, cwnd, the existing window size is greater than before by; when ECN or loss happens, cwnd is bisected.

Joined with this preservative add to multiplicative decrease (AIMD) model in which marking utters cutting the window size in partially, TCP Reno undergoes from great oscillations in throughput. The preferred congestion window utilized by TCP-Reno is approximately equivalent to the bandwidth-delay produce of the association. For high bandwidth-delay product links, this preferred congestion window is fairly far above the ground high as 80,000 packets for a 10 Gbps link with 100 ms RTT! TCP-Reno's grouping of a sluggish linear boost and a speedy multiplicative decline needs an irrational quantity of time for this preferred window to be recouped following a failure. Certainly, as highlighted by Floyd, in likely circumstances it can acquire a TCP Reno stream in excess of one hour to recuperate from a single congestion occurrence. Furthermore, beneath the random packet loss model, TCP-Reno can necessitate irrationally low packet drop likelihood for these elevated bandwidth-delay-product links. Undeniably, Reno's consideration scales with the opposite square root of the loss likelihood. To set the elevated speed networks for which the bandwidth-delay product will carry on growing, TCP Reno will turn out to be a performance restricted access itself.

During the past few years, questions concerning the behavior of TCP in speedy and long distance networks have been comprehensively concentrated on in the networking investigation community, both for the reason that TCP is the most extensive transport protocol in the up-to-date Internet and as the bandwidth-delay product keeps on growing. The renowned of TCP in high bandwidth-delay item for consumption networks is that the TCP preservative boost probing device is too slow to adapt the sending rate to the accessible bandwidth.

2. Problems of the Existing Marking/loss-Based TCP Versions

To transcend the inherent limitations of the standard TCP Reno in high-speed network several marking/loss-based protocols such as High Speed TCP (HSTCP), STCP, BIC TCP and TCP Westwood + have been proposed. By more aggressively probing for available bandwidth, and by modifying the reaction to marking/loss feedback, these protocols are able to achieve much higher throughput that TCP Reno. However, these protocols are subject to a larger number of timeouts and re-transmissions that Reno, and suffer from intra-protocol Round-Trip-Time (RTT) unfairness when competing flows have varying RTTs (R.King, 2005). Moreover, all of these protocols suffer from the reverse path congestion problem in which the throughput in the forward (source to destination) direction degrades due to unrelated congestion occurring in the reverse path (ACK packet) direction.

Both HSTCP and STCP contribute to a parallel strength as regards to their move toward to fiddle with for TCP-Reno's deficiencies, and may be regarded as selected members of the similar group of high-speed loss-based protocols. Basically modification of the window update principles of TCP-Reno can in a straight line get better the protocol's capacity to employ high speed links, but might damage its evenhandedness properties. As pointed out by Harfoush (2004) in, protocols in the same class as HSTCP and STCP (protocols that make alterations to the enlarge and decrease parameters), can have unwanted RTT equality properties if they just boost more assertively when operating with larger windows. A MIMD protocol, for example STCP, uses Multiplicative Increase and Multiplicative Decrease window adjustment regulations. For each acknowledged packet, STCP augments its clogging window by 0.01 packets, and on a packet drop, the window is decreased to 0.875 times its present window. Consequently, the revival time from a drop is scale invariant, for all time necessitating a steady number of round trip times. MIMD is corresponding to a preservative augment scheme hoer the raise step size raises proportionally to the congestion window size. (L.Xu, K.Harfoush, and I.Rhee, 2004)

The TCP alternative HSTCP takes a parallel move toward to STCP, even if it scales its drop parameter from plummeting by 50% at squat window sizes to 10% at upper windows. HSTCP after that puts its augment parameter as essential to attain its preferred packet loss comeback The finish effect is that HSTCP's boost rate raises somewhat slower as compared to that of STCP, but tranquil very quickly than TCP-Reno. A more destructive TCP version guides approximately to condensed fairness, in case care is taken. Harfoush (2004) points out that both HSTCP and STCP have unwanted equality properties at what time flows with dissimilar round trip times are opposing over a communal link. HSTCP has somewhat enhanced RTT bias performance as compared to STCP.

BIC-TCP, consistent with its authors, has desirable RTT bias properties. BIC-TCP makes use of a binary boost scheme to rapidly approach a predictable secure window, and after that gradually increase above that window. However, as pointed out by (S.Mascolo, 2006), BIC-TC, as well as other high-speed loss-based protocols, exhibits an extraordinary window fluctuation behavior with being there present turn around traffic, which is a normal network operating condition. Moreover, the number of timeouts and retransmissions is very elevated contrast with TCP Reno, which means these protocols do not put into practice as efficiently as TCP Reno does.

To tackle the danger of congestion fall down, it is of importance to mention that a common feature in all of these loss-based protocols is that they add to their congestion windows by extra to Reno's quantity of 1 packet per RTT. Since of their more destructive behavior, the above stated speedy loss-based protocols persuade congestion proceedings at a greatly advanced frequency that those persuaded by TCP-Reno. In actual fact, because of STCP's option of multiplicative amplify, STCP have to in stable state persuade congestion actions approximately all 13.4 round trip times, in spite of the connection speed. HSTCP encourages packet losses at a slower speed than STCP, but still much quicker than RCP-Reno.

3. Problems of the Existing Delay-based TCP Versions

In contrast, TCP Vegas, Enhanced TCP Vegas and FAST TCP are delay-based protocols. By relying upon changes in queuing delay measurements to detect changes in available bandwidth, these delay-based protocols achieve higher average throughout with good intra-protocol RTT fairness (Cajon, 2004). However, they have more than a few deficiencies. For instance, both Vegas and FAST suffer from the overturn path congestion difficulty, in which simultaneous onward and overturn path traffic on a simple bidirectional blockage connection cannot attain full link operation. In addition, both Vegas and Enhanced Vegas employ a conservative window increase strategy of at most one packet ever RTT, leading to slow convergence to equilibrium when ample bandwidth is available. Although possessing an aggressive window increasing strategy leading to faster convergence in high-speed networks, we shall see that, FAST has trouble grappling with uncertainty in the networking infrastructure.

Similar to Vegas and Enhanced Vegas, FAST TCP attempts to buffer a fixed number, a, of packets in the router queues in the network loop path. In speedy networks, a must be adequately big to allow a delay-based protocol to calculate the line up delay. But with great values of a, the delay-based protocol inflicts supplementary buffering necessities on the network routers with an increase in the number of flows; the router queues may not be able to handle the demand. If the buffering supplies are not fulfilled, the delay-based protocols suffer failure, which mortifies their performance. In contrast, if ? is too diminutive, the queuing delay may not be detectable, and convergence to high throughput may be slow.

Preferably, in delay-based systems a source's worth of set-point ? must be animatedly attuned consistent with the connection capacities, queuing resources, and the number of simultaneous connections in common queues. To determine a sensible and effectual technique for enthusiastically setting a perhaps time-varying set-point ? (t) has remained as an open problem. Examples of delay-based schemes include TCP Vegas (1), Enhanced TCP Vegas and FAST TCP (C.Jin, 2004). While providing higher throughput that Reno, and exhibiting good intra-RTT fairness, the delay-based schemes still have shortcomings in terms of throughput and the selection of a suitable ?. In contrast to the marking / loss-based schemes, delay-based schemes primarily do not use marking/loss within their control strategies, often choosing to follow the tactics of TCP Reno when marking or loss is selected.

4. Analytical Approaches

In terms of characterizing and providing analytical accepting of TCP congestion evasion and control, several approaches based on stochastic modeling, control theory, game theory, and optimization theory have been presented. (S.Kunniyur, 2003)

In particular, Frank Kelly gave a general analytical framework based on distributed optimization theory. In terms of providing analytical guidance to TCP congestion avoidance methods utilizing delay-based feedback, Low (S.H.Low, 2002) urbanized a duality model of TCP Vegas, interpreting TCP congestion control as a distributed algorithm to solve a global optimization problem with the round-trip delays acting as pricing information. Throughout this structure, the resultant performance improvement of TCP Vegas and Fast TCP are better understood. Nonetheless, the expansion of extra analytical framework of TCP congestion avoidance is necessary.(S.Moscolo, 2006)

Network calculus (NC) offers a scientifically thorough approach to analyze network performance, permitting a system theoretic method of decomposing network demands into impulse responses and service curves by using the notion of convolution developed within the context of a certain min-plus algebra, Previously in (R.Agrawal, 1999), window flow control strategy based on an NC using a feedback instrument was urbanized, on condition that consequences concerning the impact on the window size and performance of the session. In terms to determine the most advantageous window size, the work by R.Agrawal (1999) merely recognizes that the window size ought to be reduced when the network is crowded, and augmented when extra resources are obtainable. In (C.S.Chang, 2002), the authors extend NC analysis to time-variant settings, providing a framework useful for window flow control. However, they do not develop an optimal controller. In (F.BAcclli, 2000), a (max, +) approach similar to NC-based techniques is utilized to describe the packet-level dynamics of the loss-based TCP Reno (S.Moscolo, 2006) and Tahoe, and calculate the TCP throughput. The work in (H.Kim, 2004) utilizes NC to model and bound the throughput of Reno-type TCP flows in order to speed up simulations. (S.Moscolo, 2006)

In (J. Zhang, 2002), several NC based analytical tools useful for general resource allocation and congestion control in time-varying networks are developed. In particular, the concept of an impulse response in a certain min-plus algebra has been used and extended to characterize each network element, and the methods are utilized within a distributed sensor network scenario.

In a study on Internet related traffic, published in 1998, the dominant process transmitting over TCP were file transfer, web, remote login, email, and network news. The applications related to these processes were File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and Telecommunication network (TELENET) (Willinger, Paxton, and Taqqu, 1998). This study focuses in arrival patterns, data load, and duration with respect to packet transfer. The most frequent flow size for HTTP was about 1KB or less. At the same frequency, FTP flows sizes were about 10 times larger than HTTP.

Six years later, a flow-based traffic study of Internet application at a university campout, found that the data bulk was transferred over TCP. Two sets of data were collected for this study during a year. For each set TCP dominated the byte and packets count over the other observed protocols by about 90%. However, in terms of flows, UDP almost double the flow count of TCP for each set. In this study they found that TCP flows were over five times greater than UDP flows. They also found that over 50% of the collected flows had duration of less than 1 second. They found that in addition to FTP, new file transfer type applications had emerged. Applications such as Peer-to-Peer (P2P) and instant messaging (IM) had immerged and hand taken over as that most popular applications in terms of flows, packets, and bytes. HTTP was one of the most popular applications in terms of byte transmission and IM applications dominated in terms of flow duration (Kim, 2004).

In a similar study conducted in 2006, some of the authors of the previous article found that TCP was still dominant protocol based on bytes and packet count. UDP was still the dominant protocol in terms of flows, dominating TCP flows by twice its count. At the application level, the applications transmitting over TCP had a small changed. HTTP was the dominant application, but abnormal traffic over port 80 might had been the cause of excess bytes. One of the most popular P2P applications was eDonkey. They also found that 50% of the traffic flows were composed of 3 packets, 500 bytes or less, and duration of 1 second less (Kim, Won, and Hong, 2006).

One year later, in an hourly analysis of user-based network utilization from two Internet providers, Internet applications transmitting over TCP were found dominant. File sharing applications over TCP were found to dominate in terms of flow frequency and duration. HTTP processes was displaced to a second place (De Oliveira, 2007). The same year, a 3-year study on inbound and outbound network flows showed that the overall network traffic was dominated by HTTP flows. This study was done at a university campus where students were discouraged from accessing file sharing applications such as P2P. Data for this study was collected in 2000, 2003, and 2006. For every year of collected data, the TCP packet count significantly dominated that of UDP and Internet Control Message Protocol (ICMP). They found that flows bytes and packets were highly correlated and that flow size and duration were independent from each other (Lee and Brownlee 2007).

In 2006, a study conducted in campus wide wireless network, showed the dominant applications were web and P2P. The two types of applications contributed over 40% of the total bytes more than P2P applications. The study does not mention whether P2P application is blocked by campus network administrators. Also, the study categorizes other types of network processes and finds that although many applications do not contribute with a significant percentage of the total bytes transferred, their contribution to the total flows has an impact on the network performance (Ploumindis, Papadopouli, and Karagiannis, 2006).

These studies have tested the behavior of Internet protocols and popular applications in terms of flows, bytes, packets and duration. For the different studies, the datasets collected included data from Internet providers and university campus networks.

A weakness of the current TCP slow start mechanism becomes apparent, when there is a large delay bandwidth product (delay £ bandwidth) path. In a network path with a large round trip time (RTT) value and high bandwidth, slow start is not fast enough. For example, it takes a long time to increase cwnd for a typical satellite network (Mark Allman, 1997). In TCP Reno, self-clocking of packets is used while cwnd is limited by ssthresh (Kevin Fall and Sally Floyd, 1996). Due to self-clocking, the cwnd size does not grow fast enough if RTT is large, even though the congestion window growth rate is exponential.

If the initial ssthresh value is small in a large delay bandwidth product path, the slow start phase terminates too early, and then the cwnd increases slowly under the Additive Increase and Multiplicative Decrease (AIMD) phase of TCP Reno. To alleviate the small initial window size problem, some modifications have been suggested (M. Allman, 2002). Nevertheless, the fixed initial window size is still a problem (Ren Wang, 2004). If we have a good estimate of available bandwidth, it is reasonable to increase cwnd to the available bandwidth quicker than TCP Reno. For instance, TCP Fast Start introduced in Padmanabhan. (Venkata N, 998) uses a previous connection's cached ssthresh value for a new connection, whereas Visweswariah et al. [57] investigate the reuse of previous ssthresh value of an idle TCP connection in slow start. Both studies adopt packet pacing introduced in Aron et al. (Kevin Fall, 1996).

To accelerate cwnd growth, the slow start transmission rate can change based on the amount of available bandwidth (Venkata N, 998). When there is more available bandwidth, more packets are sent. Several ways of increasing cwnd are suggested (Venkata N, 998)

Slow start may occur in three different stages of a TCP connection -- when the connection is initially established, when the connection is idle for a while, and when there is a timeout (M. Allman, 2002). These three cases can be handled differently since the connection information available for each case is different. There have been efforts to solve each case in the literature (Vikram Visweswaraiah and John Heidemann,1997) Among these three cases, the latter two have an advantage in that they can easily acquire the states of the current connection such as the congestion window size, RTT, and its variance.

For the initial slow start, it's hard to obtain an accurate estimate of available bandwidth. Hoe (1996) uses a packet pair method to estimate the initial ssthresh value. However, the inter-packet gap of the first single packet pair is not accurate enough due to multiple hops in the path and measurement error. Furthermore, the first inter-packet gap causes overestimation of initial congestion window size (B. Melander, 2000). Multiple packet pairs are used to estimate the ssthresh value in Hu et al. (2003) and Aron et al. (1998). In Hu et al. (1996), a variant of the slow start algorithm detects the change between inter-packet gaps when the connection reaches the peak available bandwidth. The authors also use packet pacing to reduce the impact of slow start on routers.

In another approach, TCP Westwood (Ren Wang, 2004) uses an improved bandwidth estimation method of TCP Vegas (Lawrence S, 1995). This approach dynamically adjusts the slow start packet transmission rate. When there is more available bandwidth, the sending rate increases more rapidly and conversely, when there is less bandwidth available, the sending rate decreases

Although not directly related to slow start, there have been a number of studies calculating available bandwidth (C. Dovrolis, 2001). Most of these schemes use trains of packets to measure the bandwidth more accurately. Closely related to our scheme, Padmanabahn et al. (Venkata N, 1998) use the past TCP connection bandwidth as a cached value without estimating the current available bandwidth. In this scheme, routers with fair queuing capability are assumed to handle the situation when the cached value is an overestimated one.

As for the initial cwnd, Allman (Mark Allman, 1997) shows that it is beneficial to use a large initial cwnd for certain cases. Zhang et al. (2000) introduce a scheme to speed up the transfer of small files using TCP. They take a moving average of cwnd values of other connections sharing bottleneck links and the file size to be transferred, in calculating the initial cwnd value. This scheme is similar to JS in that it also bursts cwnd number of packets with packet pacing initially; however, it differs in the cwnd estimation method.

The idea of using information of other connections sharing bottleneck links has been around for nearly two decades. Savage et al. (Stefan Savage, 1999) show strong evidence of locality among network connections. This locality facilitates "informed congestion control" of other connections with the same locality. For the purpose of collecting information of connections with shared bottlenecks, a passive monitor can be adopted. Then, this information can help other connections in making congestion control decisions.

Balakrishnan et al. (1999) introduce a scheme called Congestion Manager (CM) to aggregate connection information in the OS kernel residing in between TCP and IP stacks. In addition, CM behaves as mediator of TCP and UDP flows to provide better congestion control performance using the information from multiple flows sharing the same network characteristics.

5. TCP Slow Start with Inverted Packet Pairs

In TCP (J. Postel, 1981; W. Richard Stevens, 1993), the TCP receiver sends back to the TCP sender an acknowledgement (ACK) packet for every in-order packet the TCP receiver receives from the TCP sender. Even though ACKs are small in size, they are still packets and cannot be ignored if we take into account that TCP is the dominant Internet protocol. To reduce the load on the network generated by ACKs, RFC 1122 (R. Braden, 1989) introduced the delayed acknowledgement algorithm.

When delayed acknowledgement is enabled, the TCP receiver does not acknowledge every packet. Instead, the TCP receiver starts a delay timer when it receives an in-order packet if the delay timer is not yet running. The delay timer runs for a specific duration less than or equal to 500 ms. When no packet arrives before the delay timer expires, and then the packet is acknowledged. If the next packet arrives at the TCP receiver while the delay timer is running, the newly arrived packet is acknowledged, implicitly acknowledging the previous one. When the TCP receiver receives an out-of-order packet, it should acknowledge the packet immediately regardless of delay timer state.

Statistical Model

The intent in this section we built a statistical model to verify observations that will be made regarding the variations in the number of transferred bytes per flow and how this is affected by the variations of other components that define a data flow. The purpose of this model is to find the effect that a change on the length of time during which the flows was active, the number of packets used to transfer the total bytes in a flow, and Internet protocol used to transfer the data exert on the total number of bytes transmitted by a data flow in the academic subnet.

The academic subnet model is built as follows, 1,098,465 data flows were be used to form the dataset for this subnet and this same number of observations was used for model. We are interested in the effect that other network flow components have over the flow workload. We know that the factors affecting the total bytes transmitted are the number of packets that takes to transmit the data in a flow, the length of time that the flow is active, and the Interne't protocol used to transfer the data, and therefore, Total-Packets, Duration, TCP, UDP, ICMP, and IPv6 were designated as the independent variables. And, Total-Bytes transferred are our dependent variable in this model.

The relationship between the dependent variable, Total-Bytes and the independent variables Total-Packets, Duration, TCP, UDP, ICMP and IPv6, is dictated by theory and we use multiple regressions to estimate the contribution of each parameter.

The basic principle when applying regression procedures is that all independent variables are unrelated. And the assumption is that, for each test, all other variables not being tested remain constant. The expected relationship for each independent variable against dependent variable, Total Bytes is as follows.

Number of bytes transmitted by a data flow is directly related to the total number of packets that it takes to transfer the data then i.e., and increase (decrease) on the total number of packets will result in an increase (decrease) in the bytes transmitted.

If the number of bytes transmitted by a data flow is directly related to the length of time that the flow is active then i.e., and increase (decrease) on the in the number of seconds in which the flow is active will result in an increase (decrease) in the bytes transferred.

If the number of bytes transferred by a data flow is directly related to the flow being transmitted over the TCP protocol then i.e., if the flow is transmitted over TCP, there will be an increase (decrease) in the total number of bytes transferred compared to when the flow is not transmitted over TCP.

If the number of bytes transferred is directly related to the flow being transmitted over the UDP protocol then i.e., if the flow is transmitted over UDP, there will be an increase (decrease) in the total number of bytes transferred comported to when the flow is not transmitted over UDP.

If the number of bytes transferred is directly related to the flow being transmitted over the ICMP protocol then i.e., if the flow is transmitted over ICMP, there will be an increase (decrease) in the total number of bytes transferred compared to when the flow is not transmitted over ICMP.

Categorical variable IPv6 was removed from regression testing after finding that it is a linear combination of the other categorical variables, thus making no unique contribution to the prediction of Total-Bytes. The linear combination is of the following form:

IPv6=Intercept-TCP-UDP-ICMP

This violates the basic assumption for a regression that each of the independent variables being tested must be unrelated. In general, the multiple regression procedure will estimate a model linear equation of the following form:

Total_Bytes=a+bxTotal_Packets+b1+Duration+b2xTCP+b3xUDP+b4xICMP

Where, a is the regression constant (intercept), and b1, b2, b3, b4, b5, are the estimates that will tell the amount of increase or decrease in Total Bytes that would be predicted by a unit increase in a dependent variable.