Adds fastest route vs fastest round-trip scenario

docs/Measuring-E2E-MS-Performance.md

@@ -157,15 +157,21 @@ Imagine a media service that both stores and processes high volumes of complex m
 
 ![Extended client 1 path](image/e2e-extended-client1-path.png)
 
-In the figure above the green arcs indicate service request travel whilst the blue denotes the response path. The shortest route directs the request to SFR 'B' and the consequent storage request travels on to SFR 'C'. __Responses return along the path used by the request__. Let's see the same request from client 2, who has just joined the network:
+In the figure above the green arcs indicate service request travel whilst the blue denotes the response path. The shortest route directs the request to SFR 'B' and the consequent storage request travels on to SFR 'C'. __Responses return along the path used by the request__. Indicative service response times are provided by numeric values in the active MC boxes. Let's see the same request from client 2, who has just joined the network:
 
 ![Extended client 2 path](image/e2e-extended-client2-path.png)
 
-For this client, the _locality of reference_ for processing and then storing her data is high: both of the associated MCs are located on VMs attached to the same SFR. We could expect client 2's response time to be low for this reason. _Now for the sake of example only, let us assume that the hardware running MC Processor A can only effectively handle one request at any time and that any more than this will result in a substantial degradation in processing performance_. Client 3 joins the network:
+For this client, the _locality of reference_ for processing and then storing her data is high: both of the associated MCs are located on VMs attached to the same SFR. We could expect client 2's response time to be low for this reason.
 
-__TO DO__
+_Now for the sake of example only, let us assume that the hardware running MC Processor A can only effectively handle one request at any time and that any more than this will result in a substantial degradation in processing performance_.
 
-## E2E Measurement  
+Client 3 joins the network:
+
+![Extended client 3 path](image/e2e-extended-client3-path.png)
+
+In calculating a service function route that optimizes for the complete _round trip_ delay, we need to take into account the likely delays that are incurred from both network related latencies and also service response times. The orange route illustrated above shows how the gains made by selecting a fast route through the network are offset by penalities in using a processor MC that is overloaded; conversely a slower route that selects a MC with computational resources to spare resolves to an over-all faster round-trip response time.
+
+## E2E Measurement
 
 Our aim is to aggregate network measurement points with media service measurement points to obtain a third measurement from which we can easily understand both end-to-end and round-trip performance of a media service. This is achieved by using a CLMC E2E monitoring process that aggregates data from network and media service measurements within a given sample period, e.g. every 10 seconds. This process then posts the aggregated data back to Influx in a new measurement.