openBackhaul
commented
9 months ago This requirement is problematic in several respects.
1) The devices are not supporting a threshold cross alarm for utilization. 2) Utilization puts the amount of data transmitted in the time window in relation to the transmission capacity. This always involves integration over this time window. This means that this indicator will never trigger a satisfactorily quick counter measure. 3) Utilization is not even measured and provided by the devices. Several values have to be retrieved for calculating the current utilization (which is actually a historic value as it is using data from past). Even if the necessary values would be available for retrieving, the exact calculation of the capacity is extremely complex (e.g. effect of frame size on header compression) and device type, respectively device configuration dependent. 4) Even if there would be a sufficiently precise calculation method, the necessary values would have to be retrieved at high rate to be able to trigger a satisfactorily quick counter measure.
Proposal 1: Monitoring the dropped frames instead of the utilization. droppedFramesOutput is an INT32 status attribute that could be retrieved at comparable high rate. Original link configuration would be established as soon as the value of droppedFramesOutput would increase between two measurements.
(Proposal 1a: If monitoring the dropped frames would be insufficient, we could check, whether devices are supporting the queueUtilizationList as a current performance value (current situation, instead of average value during a past period).)
Scheduling activities:
Proposal 2: A link related automation module implementing the monitoring of the droppedFramesOutput and triggering the AllTransmittersOn module in case of an increase could be provided in AIPS v1.0.0. Any more complex implementation would have to be postponed into a future release.
• Same threshold as for turning-off • if the threshold is crossed, the link must be up and running after 15 minutes at maximum
Simple time-triggering can cause network issues; the app must take into account the current traffic utilization • Turn-off cannot be based solely on time, but must be based on current traffic utilization • The utilization must be monitored continously, time granularity: 15min • There is no fixed threshold for utilization, as for links with smaller capacity the limit will be reached faster, as for links with higher capacity; Sven’s team is working on finding a suitable definition, which possibly could be used here as well • a suitable threshold must be found/defined • the treshold must be configurable • it would be better if the monitoring would run on the device itself, rather than be done from an outside app