Evolution Over Time of Network

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.

Methodology Chapter

This chapter discusses the methodology adopted for the study. The researcher used a university campus network for the purpose of study. The selected subnet network is used by the following areas: Admissions, MBA Office, Technical Staff Offices, some faculty and stuff offices, and a computer check in/out counter as a student computer lab. We did find ____ statistically assigned IP addresses. The majority of these IP addresses are assigned to network printers and some are assigned to servers running antivirus software, databases, web services, print services, and directory services. There are some test computer systems and four systems dedicated to the display of financial ticket tracking information. Users in this subnet include administrative and technical staff, faculty and student assistants.

During a 14 day observation of this subnet, we found network devices associated with the academic subnet generated ____ data flows.

The selected subnet from the ITS network is used mainly by the Network Services group. There are about ____ users in this subnet; they are network engineers, servers and system administrators, and desktop support techs. A ____computer training lab also belongs to this subnet. Training in this lab is available to all campus employees. The lab system is not used every day. Most of the computer systems in this subnet are joined to a directory server system. The users in this subnet manage the network infrastructure and data center. The data center systems do not belong to the subnet under study.

The researcher will observe subnet and explore how much data flow is generated associated with this subnet. After observation the researcher will observe the variation in the number of flows.

The flow data will be extracted from storage using Stealth Watch Management Console (Lancome, 2009) which is part of the flow data capture appliance. The Net Flow (Cisco Systems Inc., 2008) data trace files will be extracted and stored as one file per day in Comma Separated Value (CSV) format totaling 385 MB. CSV files will later be imported into statistical software for manipulation and analysis.

The flow data gathered for this study will be determined by the configuration of the Stealth Watch Xe for Net Flow appliance which is set to collect the flow data for Net Flow (Cisco Systems Inc., 2008).

For the current study, only the following flow will be used to form the datasets for each subnet, Start Active Time, Duration, Service Summary, Total Packets, and Total Bytes. The Appliance information will be eliminated since at the time of extraction, a flow data filter will be applied to only extract data collected by one device only. Therefore the appliance name will be same for all rows of collected data. The name of the appliance is irrelevant to this study. Client Zone and Server Zone will be estimated since for each subnet only one zone is listed: the zone that the subnet belongs to. Flow data extractions for each subnet will be done separately and this study does not intend to explore traffic behavior between zones. Client IP and Server IP will be used only to get a count of the number of IP addresses generating traffic within each subnet. Then the two columns holding this information will be removed from the datasets to protect the privacy of the users. Information contained in Last Time Active will be eliminated due to the necessary information being available from the duration column. Information in the Active column will be eliminated since id does not provide additional information; flow data will be filtered to extract only inactive flows. That is, only flows that have completed their transmission at the time of extraction were included. Clients Packets and Server Packets columns will be eliminated from the datasets since this study does not examine directionality of traffic; only the total number of packets exchanged by the client and server per each complete flow. Client Total Bytes and Server Total Bytes column will be also eliminated from the datasets due to this study not exploring directionality of traffic; only the total number of bytes exchanged by the client and server per each complete flow. Client Port column will be eliminated since flow association to a service or application will be done based on the server port which is contained in the Service Summary. In this study all port associations to service or applications are based on Internet Assigned Numbers Authority (IANA) well-known port numbers from 0 to 1023 (Internet Assigned Numbers Authority, 2008). In this study, observed ports outside this range, are catalogued as Unprofaned. This study assumes no misuse of these ports by any application or service.