
***********************************************

ADDITIONAL QUESTIONS

***********************************************



The network I tested was from marlin (marlin.jcu.edu.au) to manning (manning.cs.jcu.edu.au) - i.e. from Townsville to Cairns.

##############
QUESTION_1:

smallest rtt = 13658 usec = 13.658 msec

##############
QUESTION _2:

largest rtt = 8780 usec = 8.780 msecs
	NOTE: this value was somewhat of an outrider (as shown in the jpg image)

##############
QUESTION _3:

An audio server would use UDP (sending fixed length blocks to be played at 10 millisecond intervals), instead of TCP, because UDP is faster & more constant in sending/receiving information.

UDP requires less overhead than TCP (so less data needs sending).

TCP is connection oriented - which is imperative in many applications. However, in this case, you cannot afford to request (by client) & resend (by server) the datagrams you missed out on, because you need to hear the audio live. The flow has to be at a steady, constant rate.

UDP is connectionless - any lost datagram will never be recovered. HOWEVER, for live audio, the human ear wont notice a few milliseconds of dropped music; therefore the overall quality wont be affected much. In this case consistent speed is far more important than reliability.

##############
QUESTION _4:


The measurements I gathered have many implications for the design of the audio client.

The network I tested was from marlin (marlin.jcu.edu.au) to manning (manning.cs.jcu.edu.au) - i.e. from Townsville to Cairns.
I sent 50 12 byte datagrams & none were dropped.

The maximum RTT was only 13.658 milliseconds & minimum RTT was 8.780 milliseconds - a deviation of only 4.878 milliseconds, which shows the speed of arriving UDP datagrams is quick and relatively steady. Average RTT was approximately 9.52 milliseconds. I also tested the network with 100 byte datagrams, and (as you would expect), the difference (in RTT) was negligible.

However, lets not forget, that music from our audio server to our client only travels ONE WAY (i.e. average one-way trip-time of 4.76 milliseconds for Townsville to Cairns). 

Considering the quick consistent speed of the UDP packets I sent, UDP has good potential to be used between an audio server and audio client.

The audio client should be designed to receive datagrams into a long buffer. The maximum one-way trip time I saw was about 6.8 milliseconds (13.6/2), therefore, youd expect the audio client (on this network) to play "live music" at least 20 milliseconds after the real thing (representing a safety factor of over 3). The length of the buffer would allow the slower packets to still arrive before they were (periodically) removed; and the music information played to the listener. If a packet happened to go missing, the quality of music wouldnt be affected (as mentioned before).

Blocks would be sent from the audio server to the client at about the same rate as my demonstration (about 10 milliseconds apart). However, unlike my demonstration, the server wouldnt need to WAIT for a reply back - instead it would send packets in a constant stream (10 milliseconds apart).

The one-way trip-time of the packets I tested deviated by about 2.4 milliseconds (4.9/2) - therefore the client would need to allow for this.

A significant question is: how big is each block.

If the block doesnt fit into one datagram (block is over 64kB), then you'd need sent two or more packets end-to-end, and that might cause a problem. UDP is connectionless, so packets sent close together would OFTEN arrive out of order - after all, we have a deviation of about 2.4 milliseconds in one-way round trip time. To avoid the music sounding funny (with small bits of music played out of order), the client would need to make sure it was removing the correct datagram (with the correct sequence number) from the buffer.

However; if each block CAN fit in a single datagram, there is little chance of packets (sent 10 milliseconds apart), arriving out of order.

Therefore, the streaming audio server would be able to send packets to the client at a very constant rate - only very occasionally would the server drop packets, and this would be barely noticeable to the client. Even so, the client program would have to be smart enough to account for the factors I mentioned above.

##############












***********************************************

EXTRA NETWORK INFO

***********************************************



##############

REGULAR PING RESULTS:
marlin.jcu.edu.au> ping manning.cs.jcu.edu.au
PING manning.cs.jcu.edu.au (137.219.116.44): 56 data bytes
64 bytes from 137.219.116.44: icmp_seq=0 ttl=251 time=31 ms
64 bytes from 137.219.116.44: icmp_seq=1 ttl=251 time=11 ms
64 bytes from 137.219.116.44: icmp_seq=2 ttl=251 time=9 ms
64 bytes from 137.219.116.44: icmp_seq=3 ttl=251 time=10 ms
64 bytes from 137.219.116.44: icmp_seq=4 ttl=251 time=9 ms
64 bytes from 137.219.116.44: icmp_seq=5 ttl=251 time=9 ms
64 bytes from 137.219.116.44: icmp_seq=6 ttl=251 time=9 ms
64 bytes from 137.219.116.44: icmp_seq=7 ttl=251 time=9 ms

NOTE: These times are very similar to my own results - err... except for the first value.

##############

TRACEROUTE RESULTS:

marlin.jcu.edu.au> traceroute manning.cs.jcu.edu.au
traceroute to manning.cs.jcu.edu.au (137.219.116.44), 30 hops max, 40 byte packets
 1  vlan16-1 (137.219.16.1)  2 ms  1 ms  0 ms
 2  c3640tvl (137.219.3.6)  1 ms  1 ms  1 ms
 3  jcu-cns-voip (137.219.4.2)  11 ms  11 ms  11 ms
 4  vlan115-1 (137.219.115.1)  9 ms  10 ms  10 ms
 5  manningcns (137.219.116.44)  10 ms  10 ms  10 ms

##############

MY "UDP PING" RESULTS:

marlin.jcu.edu.au> udp_client -h manning.cs.jcu.edu.au -c 50
PING manning.cs.jcu.edu.au (137.219.116.44/2003) with 12 octets of data
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=1 rtt=10731 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=2 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=3 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=4 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=5 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=6 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=7 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=8 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=9 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=10 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=11 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=12 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=13 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=14 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=15 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=16 rtt=8781 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=17 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=18 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=19 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=20 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=21 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=22 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=23 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=24 rtt=13658 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=25 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=26 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=27 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=28 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=29 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=30 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=31 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=32 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=33 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=34 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=35 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=36 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=37 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=38 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=39 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=40 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=41 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=42 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=43 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=44 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=45 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=46 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=47 rtt=8780 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=48 rtt=9756 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=49 rtt=9755 usec
12 bytes from manning.cs.jcu.edu.au (137.219.116.44/2003) : seq=50 rtt=9756 usec

##############

Avg rtt = 9521.48 usecs
Min rtt = 8780 usecs
Max rtt = 13658 usecs

##############