Network Traffic and Performance - Lab Report Example

Analysing Network Traffic and Performance 1. Intrusive and NonIntrusive Monitoring Although scheduling techniques work well in managing packet flows through a network system, they suffer a common problem during periods of congestion. Since buffer space is a finite resource, under very heavy loads all space will be allocated and new arrivals must be discarded indiscriminately regardless of different classes of service. A ‘taildrop’ is a problem with TCP/IP networks with potential serious consequences. For instance, all mission or business critical traffic is dropped at the input port regardless of whether or not low-priority traffic is currently enqueued. When packets are discarder, TCP goes into a slow-start phase. Since packets are dropped indiscriminately, many sessions are affected. While this relieves the congestion, it is effectively like pulling on the emergency break every time you approach a red light. Since many TCP sessions may be affected, and all go into slow-start, this results in a situation called global synchronization, where dramatic oscillation of both congestion and low utilization occur, rather than a graceful easing off. Congestion is likely to be caused by one or more bursty traffic sources. Since packets are discarded during congestion period, those sources are unfairly penalized. Therefore, a ‘taildrop’ is effectively biased against senders (Kenyon 2002:503). For TCP this kind of bursty packet loss is particularly damaging, leading to overall inefficiency in TCP throughput for all network users. Furthermore, this problem cannot be addressed by simply increasing the memory available for queues, especially if the traffic profile is self-similar. The chaotic nature of self-similar traffic means that traffic is likely to burst beyond resource limits. We therefore need a way to intelligently pre-empt congestion that backs off senders gracefully (Kenyon 2002:503). The key to this problem is to split traffic and allow each device to deal with a fair proportion of the overall traffic. The first issue to address is whether to do this on a per-packet basis or on a flow basis. The per-packet mechanism, for instance ‘round robin’ is likely to result in fairer resource allocation but is also more likely to result in problems with retransmissions if end systems cannot re-sequence packets. It may also be harder to debug and generate accounting data. If the load is to be spread among firewalls, state synchronization may rely on flow being handled deterministically where the flow or session goes in via one interface and returns through that interface rather than session being asymmetrical (Kenyon 2002: 504). Load-sharing server clusters, fronted by a proxy server, are a common technique used on inter-networks, as they offer both resilience and scalable performance. There are a number of algorithms available to iterate new sessions fairly between servers in a group. Load can be distributed non-intelligently or intelligently, based on cost, delay, server status, and other factors. Therefore, it is useful to consider two environments for server load sharing. The case where the proxy server is local to the servers and the case where the proxy server is remotely located (Kenyon 2002:504). Basically, there are two approaches we can use to monitor session load on server pool members, non-intrusive and intrusive. Non-intrusive algorithms use simple heuristic techniques to distribute requests. On the other hand, intrusive algorithms require protocol interaction between each member of the server group and the proxy server, so that real-time status information can be passed between them. Figure 1.0 – Local Proxy Configuration Figure 2.0 – Remote Proxy Configuration a. Intrusive Network Monitoring There are many advantages of using intrusive testing approach. Perhaps the most important is that it closely mimics what the customer experiences. This approach is also useful for competitive characterisation. After subscribing to a service, as a customer would, any carrier can see the QoS that is being delivered to the customer. Intrusive network monitoring and testing can used to identify network weaknesses. Data or voice transmission in a particular area may be poor when compared to another area or processes over certain network equipment may be poor. It can establish benchmarks against which any network changes can be compared. Thus, it allows a network provided to monitor improvements to their network service. Lastly, this technique can be used to verify that network equipment is performing as expected over time (Oodan et. al. 2003). Almost all algorithms determine the capacity of servers using heuristic techniques. In practice, it is necessary to use closely coupled techniques for accurate remote prediction and status monitoring system capacity. This class of algorithm is called intrusive, since work is required on the part of the host system. Intrusive algorithms fall into broad categories such as ‘Round-trip time’, ‘Exercising content’, and ‘agent –based monitoring. A round –trip time scheme is where as server is selected for a list based on knowledge acquired using ping to periodically determine round-trip times between the proxy and each of the destination servers. The server with the shortest round-trip time should be selected. However, this algorithm has no regard for true load on the host, but clearly, the lack of response indicates that the server is unavailable or very slow. This method can be used in conjunction with heuristic techniques reasonably effectively (Kenyon 2002:506). Excising content is about advanced load balancers that can run scripts to trigger real application interaction to test the true response time of server for specific applications. For instance, a simple HTTP session could be periodically activated to test Web Server response time. Clearly, this places some additional background load on the server but remains transparent. This is a very granular way of measuring performance on servers running multiple services concurrently, since services such as FTP and HTTP can all be explicitly measures with reasonable accuracy (Kenyon 2002:506). An agent-based monitoring employs remote agent software on each server node. This interacts with monitoring software on the proxy server, providing detailed status reports concerning resource availability. The remote agent software needs to be run in the background so it does not consume excessive resources on the server. (Kenyon 2002:506) b. Nonintrusive Network Monitoring The complement to the intrusive testing technique is what is called the non-intrusive measurement and monitoring of quality. In this methodology, in a circuit switched network, equipment is bridged onto both directions of the transmissions of the call at a common point. It does not allow the measurement of accessibility or continuity, but it can measure fulfilment. For a voice call for instance, parameters like speech, noise, echo path loss and echo path delay would be measured for both direction of transmission. In an IP network, passive measurement comes from gateways and routers, which measure parameters such as packet loss. Off-line data processing analyses these values to determine the QoS. The advantage of non-intrusive testing and monitoring is that it does not add any additional load to the network. These tests can run automatically since the network is running and if frees field personnel for other tasks. A key advantage is that it does give an extensive cross section of customer calls and the ability to classify call type. This approach also naturally includes all customer equipment since it is monitoring calls already on the network. However, the disadvantage of the non-intrusive approach is that it is done inside the network offering the service so it is not really getting an end-to-end view of what the customer is experiencing. Competitive characterisations cannot be done with this methodology because access is needed to the internal portions of the network. Another disadvantage is that it can only monitor the traffic that is on the network. It cannot add any additional calls to the network to stress test any network segment (Oodan 2003:184). 2. Instructions for Test When a user encounters an error message when connecting to a web server using Internet Explorer, one should note the error number or the corresponding text. For instance, a ‘400 Bad File Request’ error normally means the syntax used in the URL is incorrect, and not web server error. However, if a web server related error occurs, here are some instructions on how to troubleshoot a particular error. a. 401 Unauthorised – in errors like this, the web server is looking for some encryption keys from your computer. This means a wrong password may have been entered and you should try it again while paying close attention to exact password. b. 408 Request Timeout- this means your computer already stopped the request before the server can retrieve it. This normally happen when a server is slow or the file too large. To verify this problem and discover the status of the server, ping that particular server. Using the command prompt, (Click on Start then Click Run and type ‘cmd’ in popup window) type ping ‘www.nameofwebsite.com’. Similar to the figure below: Figure 3.0 The remote host if available will reply to the ping and it should display the delay in microseconds. This is the time it takes the server to reply (505ms). If your are going to look at the ping statistics 4 packets were sent but only 3 were received as a result of the ‘request timed out error’ . This is because each ping packet has a timeout period thus any answer from the server is expected to be within that period. In this case, the approximate round trip time of each packet in microseconds is in the average of 575 ms. You can actually compare these results with other web servers similar to the figure below where www.bbc.co.uk was pinged. Figure 4.0 The big difference is that the web server for www.bbc.net.uk responded on time thus, no ‘request timed out’ occurred. The ping statistics shows that 4 packets were sent and 4 packets were received thus no packets were lost. 3. Network Connectivity To test network connectivity, 4 large web servers and 4 Internet trace route servers positioned on various geographical locations will be selected. Web Servers: www.bbc.co.uk - UK www.cnn.com – USA www.australia.gov.au -AUSTRALIA Trace Route Servers: Telstra (AS1221) –Australia Helios (AS517) – Germany Pacific Supernet (AS2706) - Hongkong Using the above web servers and trace route servers, we will now run a trace to observe the differences and similarities between the paths to the same server from different locations. Find the intermediate routers to each particular destination and for each trace route identify which links introduce the highest delay. First we trace route web server www.bbc.co.uk using Telstra from Australia **** traceroute to www.bbc.net.uk (212.58.253.71), 30 hops max, 40 byte packets 1 vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177) 0.386 ms 0.255 ms 0.193 ms 2 Bundle-POS1.exi-core1.Melbourne.telstra.net (203.50.6.14) 0.436 ms 0.447 ms 0.341 ms 3 Bundle-Ether2.chw-core2.Sydney.telstra.net (203.50.6.1) 15.293 ms 14.857 ms 14.805 ms 4 Port-Channel2.oxf-core1.Sydney.telstra.net (203.50.6.2) 14.969 ms 14.926 ms * 5 10GigabitEthernet2-2.syd-core03.Sydney.reach.com (203.50.13.30) 15.399 ms 15.418 ms 15.341 ms 6 i-2-0.sjc-core01.net.reach.com (202.84.140.25) 204.501 ms 204.548 ms 204.408 ms 7 unknown.net.reach.com (202.84.141.121) 259.339 ms 259.11 ms 259.102 ms 8 i-10-2.ldn-core01.net.reach.com (202.84.249.90) 345.62 ms 345.561 ms 345.536 ms 9 202.40.148.54 (202.40.148.54) 323.966 ms 324.14 ms 324.035 ms 10 bbc-gw1-linx.prt0.thdoe.bbc.co.uk (195.66.226.103) 434.399 ms 443.819 ms 427.871 ms 11 212.58.238.133 (212.58.238.133) 322.675 ms 322.623 ms 322.577 ms 12 te12-1.hsw0.cwwtf.bbc.co.uk (212.58.239.222) 325.44 ms 325.477 ms 325.551 ms Now we run a trace again on the same web server using a traceroute server from Germany. ****** traceroute to www.bbc.net.uk (212.58.228.41) from 193.141.98.37 (193.141.98.37), 30 hops max outgoing MTU = 1500 1 * pophannover.helios.de (193.141.98.1) 2 ms 2 ms 2 popcore2.pop-hannover.net (62.48.66.117) 2 ms 2 ms 1 ms 3 globalcore.pop-hannover.net (62.48.66.102) 2 ms 2 ms 2 ms 4 dcxcore.pop-hannover.net (62.48.66.58) 8 ms 8 ms 8 ms 5 dcxcore.pop-hannover.net (62.48.66.150) 8 ms 9 ms 8 ms 6 rt-decix.fft.bbc.co.uk (80.81.192.59) 11 ms 10 ms 11 ms 7 so7-0.rt0.thdo.bbc.co.uk (212.58.239.13) 24 ms 24 ms 23 ms 8 pos6-0.rt0.mh.bbc.co.uk (212.58.239.30) 27 ms 26 ms 24 ms 9 www4.mh.bbc.co.uk (212.58.228.41) 25 ms 29 ms 25 ms ***** Examining the results of the trace, aside from the IP addresses of the web server, the path is not identical in anyway. Furthermore, the delays are considerably higher from Australia than Germany. Another noticeable difference is the increasing microseconds of delay while the trace was progressing further away from the traceroute servers. Let us now run a trace to a North American web server (www.cnn.com) using the same traceroute server in Australia. ***** traceroute to www.cnn.com (64.236.16.52), 30 hops max, 40 byte packets 1 vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177) 0.414 ms 0.269 ms 0.341 ms 2 Bundle-POS1.exi-core1.Melbourne.telstra.net (203.50.6.14) 0.436 ms 0.459 ms 0.481 ms 3 Bundle-Ether2.chw-core2.Sydney.telstra.net (203.50.6.1) 14.916 ms 14.941 ms 14.82 ms 4 * Port-Channel2.oxf-core1.Sydney.telstra.net (203.50.6.2) 15.011 ms * 5 * 10GigabitEthernet2-2.syd-core03.Sydney.reach.com (203.50.13.30) 197.541 ms * 6 i-4-2.sydp-core01.net.reach.com (202.84.249.13) 15.232 ms 15.21 ms 15.134 ms 7 i-14-3.wil-core03.net.reach.com (202.84.140.162) 171.96 ms 171.768 ms 171.565 ms 8 202.84.251.222 (202.84.251.222) 170.062 ms 169.99 ms 169.9 ms 9 AOL.peer.wil03.net.reach.com (134.159.62.86) 169.869 ms 169.775 ms 169.786 ms 10 bb1-las-P0-0.atdn.net (66.185.137.128) 172.005 ms 172.382 ms 171.974 ms 11 bb2-hou-P6-0.atdn.net (66.185.152.27) 211.431 ms 211.274 ms 211.55 ms 12 bb1-hou-P1-0.atdn.net (66.185.152.152) 211.861 ms 211.455 ms 211.946 ms 13 bb1-atm-P7-0.atdn.net (66.185.152.184) 234.448 ms 234.733 ms 234.347 ms Here it appears that the route to www.cnn.com or to North America is much faster with lesser delays than a web server located in the United Kingdom. Taking a different path, it only took 234.733ms to reach www.cnn.com compared to 325.477ms of www.bbc.co.uk Let us now try to trace a North American web server for Hongkong; From traceroute.pacific.net.hk to www.cnn.com traceroute: Warning: www.cnn.com has multiple addresses; using 64.236.91.21 traceroute: Warning: Multiple interfaces found; using 202.14.67.201 @ e1000g0 traceroute to www.cnn.com (64.236.91.21), 30 hops max, 40 byte packets 1 tmhs3506-v1.pacific.net.hk (202.14.67.252) 0.632 ms 0.569 ms 2 v206.tmhc2.pacific.net.hk (202.64.154.65) 0.313 ms 0.280 ms 3 v102.wtcc2.pacific.net.hk (202.64.5.6) 0.559 ms 0.464 ms 4 202.64.3.142 (202.64.3.142) 0.508 ms 0.483 ms 5 PNT-0023.gw2.hkg3.asianetcom.net (203.192.178.73) 0.484 ms 0.506 ms 6 uunet-FE.hkix.net (202.40.161.56) 249.620 ms 254.427 ms 7 0.so-2-0-0.XT2.HKG2.Alter.Net (210.80.3.213) 259.525 ms 257.047 ms 8 0.so-1-3-3.XT2.TKO2.Alter.Net (210.80.50.61) 297.119 ms 294.244 ms 9 505.at-2-0-0.GW3.TKO5.ALTER.NET (210.80.4.86) 56.357 ms 56.426 ms 10 docomoaol-jp-gw.aspac.customer.alter.net (210.81.9.106) 296.882 ms 294.733 ms 11 bb1-tkn-P0-1.atdn.net (66.185.150.48) 298.042 ms 295.594 ms 12 bb1-sjg-P8-1.atdn.net (66.185.152.150) 421.371 ms 422.490 ms 13 bb1-ash-P15-0.atdn.net (66.185.153.58) 417.444 ms 424.300 ms 14 pop1-ash-S0-1-0.atdn.net (66.185.144.33) 234.297 ms 248.826 ms 15 dar1-mtc-S1-2-0.atdn.net (66.185.152.105) 235.176 ms 235.667 ms Tracing from the router’s IP addresses, we cannot find any similarity on its path except when the trace reaches its destination. These are evident in the IP’s 66.185.xxx.xx. On the other hand, there delays are not entirely different since they only vary by few microseconds. 4. TCP Connection A network analyzer is a combination of hardware and software. Although there are difference in each product, a network analyzer is composed of five basic parts, the hardware, capture driver, buffer, real-time analysis, and decode. Wireshark is one of the best sniffers available and is being developed as a free, commercial quality sniffer. HTTP is the most widely used protocol that supports the Web and it uses TCP to transmit data exclusively using port 80. An HTTP session begins with a client establishing a normal TCP connection and send a packet with SYN flag set. A packet is then returned from the web server with an ACK flag added to the SYN flag. Finally, the client sends a packet with the ACK flag set, and then sends another packet requesting a specific HTTP object (Orenbaugh et. al. 2007). Using network protocol analyzer Wireshark 1.0.0 (new name for Ethereal Analyzer) we capture packets from the default network interface device. Figure 5.0 Filtered by TCP protocol, the above figure shows that at time 0.0 the source started with IP 88.121.179.191 to destination 192.168.0.196. However, it has encountered a bad TCP with an incorrect TCP checksum. A few seconds later it has established a connection with 216.319.122.220 and answered back by the server at 1.090026 ms.. These network activities continue with frequent bad TCP and occasional steady connections (see Figure 6.0). Figure 6.0 – Timeline of Events Congestion is a condition of severe delay caused by an overload of datagram at one or more switching points like the router. Consequently, delays increase whenever congestion occurs and the router begins to enqueue datagram until it can forward them. In the worst case, the total number of datagram arriving at the congested router grows until the router reaches capacity and starts to drop datagram. We are noticing variations in the transmission rate as TCP is actually reducing it automatically to avoid congestion collapse. However, in a steady state on a non-congested connection, we will notice the congestion is the same as the size of the receiver’s window. Therefore, reducing the congestion window reduces the traffic TCP will inject into the connection. TCP reduces the congestion window by half of every loss thus; it decreases the window exponentially if loss continues. In other words, if congestion is likely, TCP reduces the volume of traffic exponentially and the rate of retransmission exponentially. Noticeably, the TCP congestion window gets larger after every new ACK and gets smaller when loss is detected. There are two methods in calculating the RTT (Round Trip Time). According to Fourouzan and Fegan (2002), the first one is using the timestamp option and the second measuring the time between the sending of the segment and the receiving of the acknowledgement. Each segment has a round-trip time. The value of the RTT used in the calculation of the retransmission time of the next segment is the updated value of the RTT according to the following formula (p.315). RTT=α x previous RTT+ (1-α) current RTT The value of α is usually 90 percent. This means that the new RTT is 90 percent of the value of the previous RTT plus 10 percent of the value of the current RTT. For instance, if the previous RTT is 250 microseconds and it takes a segment at this moment to be acknowledged in 70μs, the value of the new RTT and the retransmission time would be: RTT=90% x 250 + 10% x 70 = 232 μs Retransmission time = 2x 232=464μs Take for instance packet #1 from source 88.221.179.191 starting with zero at 18:21:49.134978 and the server responded sending packet # 2 at about 18:21:49.135012. The round trip time value is now 0.034 and this will be our previous RTT. In about 0.969513 microseconds interval, on packet #4 the remote server (216.239.122.220) sent another packet and it was acknowledge and received in about 0.120479ms. If we are to calculate the RTT for this TCP activity, we can now say that: RTT=90 x 0.034+ 10% x 1 or RTT=90 x 0.034+ 0.0120479x 1 RTT = 0.00306+ 0.0120479 RTT= 0.0151079 μs Thus Retransmission time = 2x0.0151079=0.302158 See Figure 7.0 Figure 7.0 The bottleneck bandwidth on the path is defined to be equal to the smallest available bandwidth of all the components on the path. Intuitively, the bottleneck bandwidth is the available capacity of the bottleneck component of this path and defines the maximum rate at which video data can be delivered on this path (Sitaram and Dan 1999:94). We will calculate the bottleneck bandwidth using the packet’s timestamp and the formula BW=(header+length) packet2/ (timestamp2-timestamp1). From our captured TCP activity, on packet #31 and #32, the timestamp is 18:21:50.579353 and 18:21:50.579381 respectively. The length of data and header for packet #32 is 100 bytes thus bottleneck bandwidth is 18:21:50.579381- 18:21:50.579353 = 0.028 ms. The header and packet length is 100*8=800 bits. We can no use our bottleneck bandwidth formula and substitute our data. BW= 800/0.028x10-3= 2857142.857 bits/sec or 2.857 MB In order to find loss packets we need to examine patterns of sending data. From packet #570 to packet #575, you will notice that the remote host was persistently sending packets notifying the local host that the previous TCP segment was lost. On the other hand, the local host only responded by sending packet #576 but repeatedly encountering a TCP checksum on its destination. This means packets are being dropped or lost during these transactions. These conditions are not isolated and its evident in some other activity. 5. Bibliography Forouzan Behrouz and Fegan Sophia Chung, 2002, TCP/IP Protocol Suite, Published 2002 McGraw-Hill Professional, ISBN: 0072460601 Kenyon Tony, 2002, Data Networks: Routing, Security, and Performance Optimization, Published 2002 Digital Press, ISBN:1555582710 Orebaugh Angela, Ramirez Gilbert, Burke Josh, Wright Joshua, Pesce Larry, and Beale Jay, 2007, Wireshark & Ethereal Network Protocol Analyzer Toolkit, Published 2007 Syngress, ISBN:1597490733 Oodan, Antony, Ward Keith, Savolaine Catherine, Daneshmand Mahmoud, Hoath Peter, 2003, Telecommunications Quality of Service Management, Institution of Electrical Engineers, Published 2003 IET, ISBN:0852964242 Sitaram Dinkar and Dan Asit, 1999, Multimedia Servers: Applications, Environments and Design, Published 1999 Morgan Kaufmann, ISBN: 1558604308 Read More