Sam Naghshineh

Connection analysis of Champaign<–> Seattle

The below analysis were done by setting up a client server relationship between two nodes, one place in University of Illinois – Coordinated Sciences labratory (Urbana-Champaign) and the other at Boeing in Seattle.

The tests were done by setting up a buffer size and transferring the specified cache size from the client to the server and clocking the speed rate, ping delay, and other various network tools to reveal our network statistics.

The connection was then further tested with ping packets and round trips. As a result it takes approximately 55ms for each packet to travel from the client to the server and another 55ms back to an average round trip time of 110ms.

From the above graph it can be seen that although the connection seems stable the speed varies constantly due to the various network settings such as MTU and packet sizes. Furthermore it can be seen from the

symmetry of the graph that the packets trip times were similar to one another. Meaning if one packet took 50ms to travel from Client to server, the same packet would also take 50ms from the Server back to the Client.

TraceRoute

By analyzing the various nodes within the path from Client to Server, further statistical data can be found such as node consistency, paths taken by the packets (Naturally the optimal path is taken the shortest

one with the least cost to take). The last hop marked in red is the client, but since the client is behind a firewall packets do not pass through the firewall and are seen as 100% loss, this is not a problem but simply a particular port should be assigned for the analysis.

A tabular format of the nodes traveled within the path is shown below followed by their respective delay.

Result

From the above traceRoute it can be seen that certain nodes may behave in an erratic way causing a peak in the overall delay of the communication. As a result depending on how fast and at what rate the

communication is required to be achieved better results can be tuned by switching the application layer or the Transport protocol of the data to achieve a higher priority within the transmission thus achieving a higher QoS.

To conclude the tests a standard ping test was also done confirming the above tests and providing a better resolution on choosing

optimum delay:

PING 12.143.248.22 (12.143.248.22) 56(84)
bytes of data.

64 bytes from 12.143.248.22: icmp_seq=1
ttl=52 time=117 ms

64 bytes from 12.143.248.22: icmp_seq=2
ttl=52 time=117 ms

64 bytes from 12.143.248.22: icmp_seq=3
ttl=52 time=116 ms

…

…

64 bytes from 12.143.248.22: icmp_seq=92

ttl=52 time=117 ms

64 bytes from 12.143.248.22: icmp_seq=93
ttl=52 time=118 ms

64 bytes from 12.143.248.22: icmp_seq=94
ttl=52 time=117 ms

— 12.143.248.22 ping statistics —

94 packets transmitted, 94 received, 0% packet loss, time 93136ms

Round trip times:

Average: 110.073ms

Minimum: 105.033ms

Maximum: 143.993ms

Standard deviation: 3.966ms

Download QOS: 92%

Upload QOS: 97%

TCP delay: 48ms

Download test type: Socket

Average download pause: 6ms

Route concurrency: 6.444185

Download TCP forced idle: 87%

As a result the system can be modeled by assuming an of average 110ms delay for transport and 48ms for application layer giving a 158ms block delay for communication (round trip).

Bidirectional Average Calculation:

(Bidirectional Send speed + Bidirectional Receive Speed)/2 = 661Kbps

Therefore:

In order to assume a seamless connection the following block can be assumed:

Round Trip Delay: 158ms

<Client Side> ———- [Delay 79ms] ———- <Server Side>

with a bidirectional average bandwidth of 661Kbps