Scaling requirements over the time program

In the scaling requirements over the time program, first we define the threshold L, The maximum amount of traffic that an instance of a NF can handle. If the traffic change of a 2 hours period is greater than L, we assume that we have to add an extra instance of the NF. We are making an assumption: the traffic flowing through the NF instance is proportionate to the capacity of the NF instance and it is same for all types of NFs. In reality this might not be correct and different NF types may have different connections between traffic flow and capacity.
As the second step, we identify the enterprises whose traffic has changed over each 2 hours from the traffic graph. For each enterprise, we have already generated x number of policies, and assume each policy has a unique traffic flow passing through. When there is a change in the total traffic for that enterprise, it is very unlikely that traffic passing through all the policies of that enterprise contributed to the traffic change. Most probably the traffic change was caused by the traffic passing through sub set of policies. So for enterprises that have a traffic change, we randomly select 5 of its policies, as the policies affected by the traffic change.
After selecting the policies affected by each enterprise traffic change, the third step is to identify which NF from each policy, needs to be scaled out/in to satisfy the new traffic demands. According to Stratos \cite{Stratos}, there are simple approaches we could leverage for deciding which NF(s) to scale. The simplest solution is to scale all NFs in that policy. This guarantees that any bottleneck will be eliminated, but this potentially wastes significant resources and imposes unneeded costs, when only one NF may be the bottleneck. So Stratos performs a set of scaling trials, scaling each NF in the policy, one (VM) instance at a time. They begin by adding a new instance of the first NF in the chain, monitoring for changes over a fixed time window. If performance improves beyond some threshold, then the new instances is permanently added to the tenant’s topology. No improvement means that the NF is not a bottleneck, so they discard the new instance. Then move to the next NF in the chain and repeat the process. Their results show that no two NFs will be simultaneously and equally bottlenecked and scaling one NF in the policy at a time is acceptable. Hence assuming the conditions in Stratos, we randomly select a NF from each policy as the bottlenecked NF for which the resource allocation needs to be increase/decrease.
The last step is to decide, from the identified NF instance to scale, how many instances we should add/remove to satisfy the new traffic demand. For each enterprise whose traffic has changed, first we identify the total traffic change over each 2 hours: $C$ from the traffic graph. Then we calculate how many instances had to be add/remove for each enterprise: $I$ based on the threshold $L$ we defined earlier.
	
	$I = C / L$
	
If we have to add/remove instances, we spread the $I$ over 2 hours (120 minutes). As explained earlier, we are trying to add/remove instance at a time. Therefore, If I = 2, and starting time of the period is T=0, then scaling occurs when T+40 minutes and T+80 minutes. If we dont have to add/remove instances, we have to change the paths of the policies which use overloaded links because of traffic change.
Following the above process, the scaling requirements over the time program is written in c++.

Inputs to the program: the set of policies, traffic pattern
Output of the program: a set of policies and NFs effected by traffic changes during each interval and the required add/remove NF instances for each interval
