Adds first draft of E2E performance analysis documentation

docs/understanding-E2E-performance.md

+# Understanding end-to-end media service performance in the FLAME platform
+
+© University of Southampton IT Innovation Centre, 2018
+
+This document describe the FLAME model of end-to-end (E2E) media service performance as it is observed and measured using the CLMC on the FLAME platform.
+
+#### **Authors**
+
+|Authors|Organisation|                    
+|-|-|
+|[Simon Crowle](mailto:sgc@it-innovation.soton.ac.uk)|[University of Southampton, IT Innovation Centre](http://www.it-innovation.soton.ac.uk)|
+
+## Introduction
+
+Readers of this document are assumed to have at least read the [CLMC information model](clmc-information-model.md). Here we explore the requirements which inform the definition of metrics that determine *'end-to-end'* media service performance. Before continuing, some terms are defined:
+
+| term | definition |
+| --- | --- |
+| *client* | an end-user of a FLAME media service - typically somebody accessing the service via an mobile computing device connected to an _EP router_ |
+| *endpoint* | an endpoint (EP) is a virtual machine (VM) connected to the FLAME network |
+| *service router* | an EP that allows other EPs to communicate with one another using fully qualified domain names (FQDN), rather than IP addresses |
+| *network node* | an _EP_, _service router_ or other hardware that receives and sends network traffic along network connections attached to it |
+| *media component* | a media component (MC) is a process that in part or wholly realizes the functionality of a media service |
+| *E2E path* | the directed, acyclic traversal of FLAME network nodes, beginning with a source _EP_ and moving to a target _EP_ via network nodes in the FLAME network |
+| *round trip time* | the total time taken for a service request to i) traverse an _E2E path_, ii) be processed at the _MC_, iii) be returned as a response via an _E2E path_
+
+In the sections that follow we set out some basic properties of a potential media service and then explore these in more detail with a concrete example. Following on from this analysis we provide a test-based approach to the specification of E2E media service performance measures.
+
+## E2E SFC chains
+
+Let us begin by identifying some simple, generic interactions within a media service function chain (SFC):
+
+```
+// simple chain
+Client --> data storage MC
+
+// sequential chain
+Client --> data processor MC --> data storage MC
+
+// complex chain
+Client --> data processor MC_A --> data processor MC_B
+                               |-> data storage MC <-|
+```
+
+The first example above imagines a client simply requesting some data be stored in (or retrieved from) a database managed by the MC responsible for persistence. In the second case, the client requests some processing of some data held in the data store, the results of which are also stored. Finally, the third case outlines a more complex scenario in which the client requests some processing of data which in turn generates further requests for additional data processing in other MCs which also may depend on storage I/O functionality. Here additional data processing by related MCs could include job scheduling or task decomposition and distribution to worker nodes. An advanced media service, such as a modern computer game, is a useful example of such a service in which graphics rendering; game state modelling; artificial intelligence and network communications are handled in parallel using varying problem decomposition methods.
+
+## E2E simple chain
+
+Next we will define a very simple network into which we will place a data processing EP and a data storage EP - we assert the clients could connect to any of _service routers_ that link these MC together.
+
+![Simple E2E network](image/e2e-simple-chain-network.png)
+
+Our simple network consists of three _service routers_ that connect clients with MC data and storage functionality; each demand from client 1 for the storage function could be routed in one network hop from router 'A' to router 'C' or in two from routers 'A' -> 'B' -> 'C'. A demand for storage function from _client 2_ would include zero network hops.
+
+### E2E simple chain metrics
+
+A principal metric we use to understand E2E performance is mean end-to-end _delay_: the average time taken between a request or response being transmitted and received _within the FLAME network_. Scoping the E2E delay to within the FLAME network is an important qualification since it is only within this network that all necessary measurements can reliably be taken.
+
+An out-going simple E2E request chain looks like this:
+
+![Simple E2E request steps](image/e2e-simple-chain-request-steps.png)
+
+the delay associated with the processing of the service request is isolated to within the storage MC:
+
+![Simple E2E MC processing](image/e2e-simple-chain-mc-processing.png)
+
+whilst for the response E2E delay, we see this:
+
+![Simple E2E response steps](image/e2e-simple-chain-response-steps.png)
+
+Above we denote the time required for an service router to handle (or pass on) an in-coming message as _handle request_ or _handle response_. When a message is first encountered by a service router, an optimized path through the FLAME network must also be determined; this is labelled above as _route specification_. The _round trip time_ is the sum of the request, service processing and response delays.
+
+> __Side note:__
+> To understand _delay_ more robustly, we may also consider the rate at which requests or responses arrive (_arrival rate_) at each node in the network since message management (queuing, for example) will have an effect at scale. Similarly, the _payload size_ of the messages being handled could also be observed since the quantity of data traversing the SFC will also impact delay in similar, large scale scenarios.
+>
+
+
+### E2E simple chain performance query