Expands conclusion to include measurement and prediction

docs/total-service-request-delay.md

@@ -175,28 +175,26 @@ The total delay is:
 total_delay = forward_network_delay + service_delay + reverse_network_delay
 ```
 
-To measure or predict the `total_delay` we need:
+To *measure* the `total_delay` we need:
 
 ```
 total_delay = forward_latency + forward_data_delay + service_delay + reverse_latency + reverse_data_delay
             = forward_latency
                 + {(8 / 1E6) * (request_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
-                + request_size * service_function_scaling_factor / cpus
+                + service_delay
                 + reverse_latency
                 + {(8 / 1E6) * (response_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
 ```
 
 With:
 
-* forward_latency / s
-* request_size / Bytes
-* bandwidth / Mb/s   (b = bit)
-* packet_size / Bytes
-* packet_header_size / Bytes
-* service_function_scaling_factor / Mflops/Byte
-* cpus (unitless)
-* reverse_latency / s
-* response_size / Bytes
+* forward_latency / s (measured by network probe)
+* reverse_latency / s (measured by network probe)
+* request_size / Bytes (measured at service)
+* response_size / Bytes (measured at service)
+* bandwidth / Mb/s   (b = bit) (assumed constant and known or measured)
+* packet_size / Bytes (constant and known)
+* packet_header_size / Bytes (constant and known)
 
 This calculation assumes:
 
@@ -209,3 +207,21 @@ This calculation assumes:
 * that the service delay is inversely proprtional to the number of CPUs (and all CPUs are equal)
 * that the compute resource is invariable, 100% available and 100% reliable
 * that the distribution of API calls is constant and that the workload can be represented sufficiently by the average request size
+
+To *predict* the `total_delay` we need:
+
+```
+total_delay = forward_latency + forward_data_delay + service_delay + reverse_latency + reverse_data_delay
+            = forward_latency
+                + {(8 / 1E6) * (request_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
+                + request_size * service_function_scaling_factor / cpus
+                + reverse_latency
+                + {(8 / 1E6) * (response_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
+```
+
+With:
+
+* service_function_scaling_factor / Mflops/Byte (known, somehow)
+* cpus (unitless) (known)
+
+As discussed above, you could also predict the latency if you know the length of a link but this seems a bit too theoretical.
\ No newline at end of file