Skip to content
Snippets Groups Projects
Commit 0dbbda49 authored by Nikolay Stanchev's avatar Nikolay Stanchev
Browse files

Issue #68 - Updated docs with 'network delay monitoring' section

parent ae027d2a
Branches
Tags
No related merge requests found
......@@ -245,10 +245,53 @@ time response_time
```
The script will merge those rows, beucase there is a match on network delay target SFR and service delay SFR - namely **SFR-B**.
The script will merge those rows, because there is a match on network delay target SFR and service delay SFR - namely **SFR-B**.
| path_ID (tag) | source_SFR (tag) | target_SFR (tag) | FQDN (tag) | sf_instance (tag) | delay_forward | delay_reverse | delay_service | time |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| SFR-A---SFR-B | SFR-A | SFR-B | ms-A.ict-flame.eu | test-sf-clmc-agent-build_INSTANCE | 9.2 | 10.3 | 11 | 1524833145975682287 |
The resulting row would then be posted back to influx in the **e2e_delays** measurement.
## Monitoring
### Monitoring network delays
Here, we describe the process of obtaining network delays between two service function routers in the network topology.
CLMC retrieves the network topology graph from the monitoring framework and the link delays between any two network nodes.
Example (**SR** denotes a service router, **S** denotes a switch):
![networg_graph](image/network_graph.png)
SFR monitoring provides us with FIDs at each service router, which are bidirectional path IDs. From those, we derive the desired SR-SR network latencies.
For instance, if we take the network graph example and analyse service router **SR3**. We would get 2 FIDs for this router - one for the path to reach SR2
and one for the path to reach SR1.
We assume that the FID for reaching *SR1* from *SR3* tells us the path goes through nodes *S3* and *S6*.
![networg-SR3-SR1](image/network-SR3-SR1.png)
Hence, we accumulate the individual link delays to derive the full SR-SR delay for both forward and reverse direction.
delay_forward = SR3-S3 + S3-S6 + S6-SR1 = 12 + 3 + 3 = 18
delay_reverse = SR1-S6 + S6-S3 + S3-SR3 = 1 + 5 + 10 = 16
Now, we assume that the FID for reaching *SR2* from *SR3* tells us the path goes through nodes *S4* and *S2*.
![networg-SR3-SR1](image/network-SR3-SR2.png)
Hence, we accumulate the individual link delays to derive the full SR-SR delay for both forward and reverse direction.
delay_forward = SR3-S4 + S4-S2 + S2-SR2 = 12 + 4 + 5 = 21
delay_reverse = SR2-S2 + S2-S4 + S4-SR3 = 8 + 2 + 11 = 21
Overall, from this analysis, the following data will be reported to Influx in the **network_delays** measurement:
| path (tag) | source (tag) | target (tag) | delay | time |
| --- | --- | --- | --- | --- |
| SR3-SR1 | SR3 | SR1 | 18 | 1525334761282000 |
| SR3-SR1 | SR1 | SR3 | 16 | 1525334761282000 |
| SR3-SR2 | SR3 | SR2 | 21 | 1525334761282000 |
| SR3-SR2 | SR2 | SR3 | 21 | 1525334761282000 |
### Monitoring media service response times
\ No newline at end of file
File suppressed by a .gitattributes entry or the file's encoding is unsupported.
File suppressed by a .gitattributes entry or the file's encoding is unsupported.
File suppressed by a .gitattributes entry or the file's encoding is unsupported.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment