Merge branch 'integration' of gitlab.it-innovation.soton.ac.uk:FLAME/flame-clmc into integration

clmctest/monitoring/StreamingSim.py

@@ -392,19 +392,41 @@ class Sim(object):
         Calculates the network delay. Declared as static method since it doesn't need access to any instance variables.
 
         :param distance: distance metres
-        :param bandwidth: bandwidth Mbps
+        :param bandwidth: bandwidth Mb/s
         :param packet_size: packet size bytes
-        :param tx_video_bit_rate: bp/sec
+        :param tx_video_bit_rate: Mb/s
         :return: the calculated network delay
         """
 
         # propogation delay = distance/speed () (e.g 2000 metres * 2*10^8 for optical fibre)
+        # This is how long it takes to get a signal from one end to the other
+        # We are using 2E8 here rather than the speed of light (3E8) presumably because in optical fibre there are other delays with the repeaters etc?
+        # Isn't propogation_delay the same as "latency"?
+        # http://www.m2optics.com/blog/bid/70587/Calculating-Optical-Fiber-Latency suggests optical fibre is 5 microseconds / km
+        # 5 microseconds / km is 1/5  km / microsecond =  1000/5 m / microsecond = 1000000000/5 m/s = 2 * 100000000
+        # In reality we would measure the latency of a link.
         propogation_delay = distance / (2 * 100000000)
+
         # packetisation delay = ip packet size (bits)/tx rate (e.g. 100Mbp with  0% packet loss)
+        # This is how long it takes a whole data packet to pass a point in the wire
         packetisation_delay = (packet_size * 8) / (bandwidth * 1000000)
+
         # total number of packets to be sent
+        # This claims to be number of packets, but is actually is some sort of rate: the units are per second.
+        # If the tx_video_bit_rate was actually the size of the data to be sent then the formula is correct.
         packets = (tx_video_bit_rate * 1000000) / (packet_size * 8)
 
+        # This should be time for a data point to get from one end to the other (propogation_delay) +
+        #   time delay from the start of the data passing a point until the end of the data passes the point
+        # = propogation_delay + (total data size / bandwidth)
+        #
+        # A packet on the network comprises a data payload and a header. The header size is constant for a particular protocol 
+        # and the total packet size can be configured (e.g. 1500 bytes).
+        # packet_size = packet_header_size + packet_payload_size
+
+        # The total data size ideally would be (data size / (packet size - header size)) * packet size
+        # response_delay = propogation_delay + {[(data size / (packet size - header size)) * packet size] / bandwidth}
+        # response_delay = latency + {[(data_size / (packet_size - packet_header_size)) * packet_size] / bandwidth}
         response_delay = packets * (propogation_delay + packetisation_delay)
 
         return response_delay

docs/total-service-request-delay.md

+# Round Trip Time of a Service Request
+
+The Round Trip Time (RTT) of a network is the time taken from sending a packet to receiving the acknowlegement. We are also interested in factoring in the size of the data being sent over the network and the delay caused by the service processing the request.
+
+```
+total_delay = forward_network_delay + service_delay + reverse_network_delay
+```
+
+## Network delay
+
+Time to send complete payload over network
+
+network_delay = time delay from first byte leaving source to final byte arriving at destination
+
+If we ignore the OSI L6 protocol (e.g. HTTP, FTP, Tsunami) then we are modelling a chunk of data moving along a wire. The network delay is then:
+
+```
+network_delay = latency + (time difference from start of the data to the end of the data)
+```
+
+### Latency
+
+The latency (or propagation delay) of the network path is the time taken for a particular bit of data to get from one end to the other. If we are just modelling one wire (with no switches) then this can be modelled using:
+
+latency = distance / speed
+
+For optical fibre (or even an eletric wire), the speed naively would be the speed of light. In fact, the speed is slower than this (in optical fibre this is because of the internal refraction that occurs, which is different for different wavelengths). According to http://www.m2optics.com/blog/bid/70587/Calculating-Optical-Fiber-Latency the delay (1/speed) is approximately 5 microseconds / km
+
+```
+if 
+    distance is in m
+    delay is in s/m
+    latency is in s
+then
+    latency = distance * 5 / 1E9
+```
+
+(this matches MJB's "propogation_delay" formula)
+
+Normally we would just measure the latency of a link. Most real-life connections comprise many network links and many switches, each of which introduces some latency.
+
+### Data delay
+
+The time difference from start of the data to the end of the data (or "data delay" for want of a better term) is dependent on the bandwidth of the network and the amount of data.
+
+```
+if
+    data_size is in Bytes
+    bandwidth is in Mb/s
+    data_delay is in s
+then 
+    data_delay = data_size * 8 / bandwidth * 1E6
+```
+
+The data_size naively is the size of the data you want to send over the network (call this the "file_size"). However, the data is split into packets and each packet has a header on it so the amount of data going over the network is actually more than the amount sent.
+
+```
+let 
+    packet_size = packet_header_size + packet_payload_size
+then
+    data_size = (packet_size / packet_payload_size) * file_size
+or
+    data_size = (packet_size / packet_size - packet_header_size) * file_size
+```
+
+### Total delay
+
+```
+delay = latency + data_delay
+    = (distance * 5 / 1E9) + {[(packet_size / packet_size - packet_header_size) * file_size] * 8 / bandwidth * 1E6}
+```
+
+### Effect of Protocol
+
+The choice of protocol has a large effect in networks with a high bandwidth-delay product.
+
+In data communications, bandwidth-delay product is the product of a data link's capacity (in bits per second) and its round-trip delay time (in seconds). The result, an amount of data measured in bits (or bytes), is equivalent to the maximum amount of data on the network circuit at any given time, i.e., data that has been transmitted but not yet acknowledged.
+
+TCP for instance expects acknowledgement of every packet sent and if the sender has not received an acknowledgement within a specified time period then the packet will be retransmitted. Furthermore, TCP uses a flow-control method whereby the receiver specifies how much data it is willing to buffer and the sending host must pause sending and wait for acknowledgement once that amount of data is sent.
+
+## Service Delay
+