Ouroboros Metrics - Revision history

Dimitri: /* Step by step instructions to run the exporter */

2024-07-21T11:37:01Z

Step by step instructions to run the exporter

← Older revision		Revision as of 11:37, 21 July 2024
Line 38:		Line 38:
	== Step by step instructions to run the exporter ==		== Step by step instructions to run the exporter ==

	On each of the machines running O7s, install the exporter		On each of the machines running O7s, clone the metrics repository and install the exporter

	git clone https://ouroboros.rocks/git/ouroboros-metrics		git clone https://ouroboros.rocks/git/ouroboros-metrics

Dimitri: /* Set up Grafana */

2024-07-21T11:36:16Z

Set up Grafana

← Older revision		Revision as of 11:36, 21 July 2024
Line 28:		Line 28:
	To add the Ouroboros dashboard, select Dashboards -> Manage -> Import		To add the Ouroboros dashboard, select Dashboards -> Manage -> Import

	and then either upload the json file from the metrics repository in		and then either upload the json file from the metrics repository (see next step) in

	dashboards-grafana/general.json		dashboards-grafana/general.json

Dimitri: /* Set up Grafana */

2024-07-21T11:35:44Z

Set up Grafana

← Older revision		Revision as of 11:35, 21 July 2024
Line 30:		Line 30:
	and then either upload the json file from the metrics repository in		and then either upload the json file from the metrics repository in

	dashboards-grafana/general.json		dashboards-grafana/general.json

	or copy the contents of that file to the “Import via panel json” textbox and click “Load”.		or copy the contents of that file to the “Import via panel json” textbox and click “Load”.

Dimitri: /* Step by step instructions */

2024-07-21T11:35:10Z

Step by step instructions

← Older revision		Revision as of 11:35, 21 July 2024
Line 36:		Line 36:
	The dashboard in the repository assumes the bucket name to be ''ouroboros-metrics'', and will require editing if you want to use a different bucket name.		The dashboard in the repository assumes the bucket name to be ''ouroboros-metrics'', and will require editing if you want to use a different bucket name.

	== Step by step instructions ==		== Step by step instructions to run the exporter ==

	On each of the machines running O7s, install the exporter		On each of the machines running O7s, install the exporter

Dimitri at 11:34, 21 July 2024

2024-07-21T11:34:04Z

← Older revision		Revision as of 11:34, 21 July 2024
Line 1:		Line 1:
	~~{{Under construction}}~~

	[[File: Grafana_dashboard_demo.png\|800px\|border\|none\|Ouroboros Dashboard]]		[[File: Grafana_dashboard_demo.png\|800px\|border\|none\|Ouroboros Dashboard]]

Dimitri: /* Panels */

2024-07-21T11:33:39Z

Panels

← Older revision		Revision as of 11:33, 21 July 2024
Line 163:		Line 163:

	These 4 panels show the management traffic sent by the ''flow allocators''. Currently this traffic is only related to congestion avoidance. The example here is taken from a jFed experiment during a period of congestion. The receiver IPCP monitors packets for congestion markers and it will send an update to the source IPCP to inform it to slow down. It shows the rate of flow updates for multi-bit Explicit Congestion Notification.		These 4 panels show the management traffic sent by the ''flow allocators''. Currently this traffic is only related to congestion avoidance. The example here is taken from a jFed experiment during a period of congestion. The receiver IPCP monitors packets for congestion markers and it will send an update to the source IPCP to inform it to slow down. It shows the rate of flow updates for multi-bit Explicit Congestion Notification.

			=== Congestion Avoidance ===

			[[File: Grafana_ipcp_np1_cc.png\|1200px\|border\|frameless\|none\|Congestion Avoidance panel in the grafana dashboard]]

			This is a more detailed panel that shows the internals of the Multi-Bit Explicit Congestion Notification (MB-ECN) congestion avoidance algorithm.

			The left side shows the congestion window width, which is the timeframe over which the algorithm is averaging bandwidth. This scales with the packet rate, as there have to be enough packets in the window to make a reasonable measurement. Biggest change compared to TCP is that this window width is independent of RTT. The congestion algorithm then sets a target for the maximum number of bytes to send within this window (congestion window size). The division of the number of bytes that can be sent and the size of the windows yields the target bandwidth. The congestion was caused by a 100Mbit link, and the target set by the algorithm is quite near this value. The congestion level is a quantity that controls the rate at which the window scales down when there is congestion. This upstream/downstream view should be as close as possible to identical, the reason they are not is because of the jitter and loss in the flow updates as observed above. Work in progress.

			The graphs also show the number of packets and bytes in the current congestion window. The default target is set to min 8 and max 64 packets within the congestion window before it scales up/down.

			And finally, the upstream packet counters shows the number of packets sent without receiving a congestion update from the receiver, and the downstream packet counter shows the number of packets received since the last time there was no congestion.

			=== Data Transfer Local Components ===

			The last panel shows the (management) traffic sent and received by the IPCP internal as measured by the forwarding engine (Data transfer).

			[[File: Grafana_ipcp_dt_dht.png\|1200px\|border\|frameless\|none\|Congestion Avoidance panel in the grafana dashboard]]

			The components that are current shown on this panel are the DHT (Directory) and the Flow Allocator. As you can see, the DHT didn’t do much during this interval. That’s because it is only needed for name-to-address resolution and it will only send/receive packets when an address is resolved or when it needs to refresh its state, which happens only once every 15 minutes or so.

			[[File: Grafana_ipcp_dt_fa.png\|1200px\|border\|frameless\|none\|Congestion Avoidance panel in the grafana dashboard]]

			The bottom part of the local components is dedicated to the flow allocator. During the monitoring period, only flow updates were sent, so this is the same data as shown in the flow management traffic, but from the viewpoint of the forwarding element in the IPCP, so it shows actual bandwidth in addition to the packet rates.

Dimitri: /* IPCP N+1 Flows */

2024-07-21T11:25:42Z

IPCP N+1 Flows

← Older revision		Revision as of 11:25, 21 July 2024
Line 154:		Line 154:
	=== IPCP N+1 Flows ===		=== IPCP N+1 Flows ===

	[[File: ~~Grafana_frcp_flows_np1~~.png\|1200px\|border\|frameless\|none\|IPCP N+1 Flows panel in the grafana dashboard]]		[[File: Grafana_ipcp_np1.png\|1200px\|border\|frameless\|none\|IPCP N+1 Flows panel in the grafana dashboard]]

	These graphs show basic statistics from the point of view of the IPCP that is serving the application flow. It shows upstream and downstream bandwidth and packet rates, and total sent and received packets/bytes.		These graphs show basic statistics from the point of view of the IPCP that is serving the application flow. It shows upstream and downstream bandwidth and packet rates, and total sent and received packets/bytes.

Dimitri: /* N+1 Flow Management */

2024-07-21T11:25:10Z

N+1 Flow Management

← Older revision		Revision as of 11:25, 21 July 2024
Line 160:		Line 160:
	=== N+1 Flow Management ===		=== N+1 Flow Management ===

	[[File: ~~Grafana_frcp_np1_mgmt~~.png\|1200px\|border\|frameless\|none\|N+1 Flow Management panel in the grafana dashboard]]		[[File: Grafana_ipcp_np1_mgmt.png\|1200px\|border\|frameless\|none\|N+1 Flow Management panel in the grafana dashboard]]

	These 4 panels show the management traffic sent by the ''flow allocators''. Currently this traffic is only related to congestion avoidance. The example here is taken from a jFed experiment during a period of congestion. The receiver IPCP monitors packets for congestion markers and it will send an update to the source IPCP to inform it to slow down. It shows the rate of flow updates for multi-bit Explicit Congestion Notification.		These 4 panels show the management traffic sent by the ''flow allocators''. Currently this traffic is only related to congestion avoidance. The example here is taken from a jFed experiment during a period of congestion. The receiver IPCP monitors packets for congestion markers and it will send an update to the source IPCP to inform it to slow down. It shows the rate of flow updates for multi-bit Explicit Congestion Notification.

Dimitri: /* Delta-t window */

2024-07-21T11:24:20Z

Delta-t window

← Older revision		Revision as of 11:24, 21 July 2024
Line 148:		Line 148:
	=== Delta-t window ===		=== Delta-t window ===

	[[File: ~~Grafana_frcp_windows~~.png\|1200px\|border\|frameless\|none\|Delta-t Windows panel in the grafana dashboard]]		[[File: Grafana_frcp_window.png\|1200px\|border\|frameless\|none\|Delta-t Windows panel in the grafana dashboard]]

	The third panel related to FRCP is the window panel that shows information regarding Flow Control. FRCP flow control tracks the number of packets in flight. These are the packets that were sent by the sender, but have not been read/acknowledged yet by the receiver. Each packet is numbered sequentially starting from a random value. The default maximum window size is currently 256 packets.		The third panel related to FRCP is the window panel that shows information regarding Flow Control. FRCP flow control tracks the number of packets in flight. These are the packets that were sent by the sender, but have not been read/acknowledged yet by the receiver. Each packet is numbered sequentially starting from a random value. The default maximum window size is currently 256 packets.

Dimitri: /* Panels */

2024-07-21T11:22:34Z

Panels

← Older revision		Revision as of 11:22, 21 July 2024
Line 123:		Line 123:

	The Link State Database panel shows the knowledge each IPCP has about the network routing area(s) it is in. This simple example has 2 IPCPs that are directly connected, so each knows 1 neighbor (the other IPCP), 2 nodes, and two links (each unidirectional arc in the topology graph is counted).		The Link State Database panel shows the knowledge each IPCP has about the network routing area(s) it is in. This simple example has 2 IPCPs that are directly connected, so each knows 1 neighbor (the other IPCP), 2 nodes, and two links (each unidirectional arc in the topology graph is counted).

			=== Process N-1 Flows ===

			[[File: Grafana_frcp.png\|1200px\|border\|frameless\|none\|Process N-1 Flows panel in the grafana dashboard]]

			This is the first panel that deals with the Flow-and-Retransmission Control Protocol (FRCP). It shows metrics for the flows between the applications (this is not the same flow as the data transfer flow above, which is between the IPCPs). This panel shows metrics relating to retransmission. The first is the current retransmission timeout, i.e. the time after which a packet will be retranmitted. This is calculated from the smoothed round-trip time and its estimated deviation (well below 1ms), as estimated by FRCP.

			The flow is created by the oping application that is pinging at a 10ms interval with packet retransmission enabled (so basically a service equivalent as running ping over TCP). The main difference with TCP is that Ouroboros flows are between the applications themselves. The oping server immediately responds to the client, so the client sees a response time well below 1 ms1. The server, however, sees the client sending a packet only every 10ms and its RTO is a bit over 10ms. The ACKs from the perspective of the server are piggybacked on the client’s next ping. (This is similar to TCP “delayed ACK”, the timer in Ouroboros is set to 10ms, so if I would ping at 1 second intervals over a flow with FRCP enabled, the server would also see a 10ms Round-trip time).

			=== Delta-t constants ===

			The second panel to do with FRCP are the Delta-t constants. Delta-t is the protocol on which FRCP is based.

			[[File: Grafana_frcp_constants.png\|1200px\|border\|frameless\|none\|Delta-t Constants in the grafana dashboard]]

			A quick refresher on these Delta-t timers as used in Ouroboros:

			* '''Maximum Packet Lifetime (MPL)''' is the maximum time a packet can live in the network, default is 1 minute.

			* '''Retransmission timeout (R)''' is the maximum time which a retransmission for a packet may be sent by the sender. The default is 2 minutes. The first retransmission will happen after RTO, then 2 * RTO, 4* RTO and so on with an exponential back-off, but no packets will be sent after R has expired. If this happens, the flow is considered failed / down.

			* '''Acknowledgment timeout (A)''' is the maximum time for which an packet may be acknowledged by the receiver. Default is 10 seconds. So a packet may be acknowledged immediately, or after 10 milliseconds, or after 4 seconds, but not any more after 10 seconds.

			=== Delta-t window ===

			[[File: Grafana_frcp_windows.png\|1200px\|border\|frameless\|none\|Delta-t Windows panel in the grafana dashboard]]

			The third panel related to FRCP is the window panel that shows information regarding Flow Control. FRCP flow control tracks the number of packets in flight. These are the packets that were sent by the sender, but have not been read/acknowledged yet by the receiver. Each packet is numbered sequentially starting from a random value. The default maximum window size is currently 256 packets.

			=== IPCP N+1 Flows ===

			[[File: Grafana_frcp_flows_np1.png\|1200px\|border\|frameless\|none\|IPCP N+1 Flows panel in the grafana dashboard]]

			These graphs show basic statistics from the point of view of the IPCP that is serving the application flow. It shows upstream and downstream bandwidth and packet rates, and total sent and received packets/bytes.

			=== N+1 Flow Management ===

			[[File: Grafana_frcp_np1_mgmt.png\|1200px\|border\|frameless\|none\|N+1 Flow Management panel in the grafana dashboard]]

			These 4 panels show the management traffic sent by the ''flow allocators''. Currently this traffic is only related to congestion avoidance. The example here is taken from a jFed experiment during a period of congestion. The receiver IPCP monitors packets for congestion markers and it will send an update to the source IPCP to inform it to slow down. It shows the rate of flow updates for multi-bit Explicit Congestion Notification.