Dynamically changing traffic over time

[stefanbschneider]

Currently, our simulator supports deterministic or stochatically distributed traffic, generating flows around a predefined avg inter-arrival time and data rate.

At some point, it would be nice to also test the RL agent with traffic that's dynamically and gradually changing over time. Eg, gradually increasing traffic where the inter-arrival time slowly decreases; or vice versa.

I'm still not sure what would be the best way to specify and implement this in a way that's both simple and useful. Ideally, we should also be able to run pre-recoded traces from http://sndlib.zib.de (where we have traffic recorded for every 5min or so).

Before any implementation happens, we should discuss ideas and approaches first.

[qarawlus]

Will see what ideas I can add to this. Initial thoughts: Not so straightforward to implement.

I had a look through the traffic traces, the way the simulator is created right now heavily depends on the fact that it is the one generating traffic, so we cannot push traces through it. Perhaps we could analyse the trace and provide parameters to the simulator that can generate similar traffic.

I will, time permitting, look into this and give a complete concept on what to do to achieve it.

Should we keep it at priority medium for now, or shift it to low until we finish working with the RL agent?

[stefanbschneider]

RL agent is still higher priority. If it works well with the RL agent and we go for a publication. A trace-driven evaluation would greatly enhance our evaluation and chance for acceptance. So we should think a bit about how to do this in parallel, so that we can then hopefully implement it quite quickly once/if we need it. But I agree, rather lower priority for now.

Regarding the implementation, I was also thinking that we just interpret the traces in some pre-processing module and use them to give changing inputs to the simulator. So the simulator will stay the one generating traffic.

But we still need a way to change inter-arrival time during simulation. For the specification, maybe something like: Start with arrival time x and increase it in steps of y every z steps to arrival time xyz.

[qarawlus]

If we do add a module to handle the processing of traffic traces, then changing the parameter mid simulation should not be difficult, Inter arrival mean is now set in SimulatorParams, and changing it through a calling module is very simple.

[stefanbschneider]

Yes, but we would want to change the arrival time during simulation without restarting it.

[qarawlus]

The inter arrival mean is checked with every flow generation, so we don't need to restart the simulation to change it.

[stefanbschneider]

It's reading from file every time? Or does it just check the attribute, which is set once at the beginning?

[qarawlus]

The attribute inside SimulatorParams is checked. It can be changed in the same way the interface changes the schedule and placement.

[stefanbschneider]

Got it. So currently, the simulator reads the inter-arrival time and sets it once in the init of SimulatorParams: https://github.com/RealVNF/coordination-simulation/blob/master/src/coordsim/simulation/simulatorparams.py#L31

But the SimulatorParams attribute, which is checked when generating new flows, can also be adjusted during runtime, similar like other params (placement, schedule) are adjusted during apply: https://github.com/RealVNF/coordination-simulation/blob/master/src/siminterface/simulator.py#L80

Sounds good. For me, an open question is still how/when we'd set new parameter values. The whole execution flow is in the simulator, so it would be the one that has to "ask" for updated arrival times. Maybe one approach would be to replace the check for the attribute self.params.inter_arr_mean with a function call self.params.inter_arrival_time(). We could then implement whatever we want for that in a separate module. The default would still simply return the fixed value that's read from the config file in the beginning. But we could also implement different functionality, eg, that parses a trace and returns new arrival times depending on the trace.

What do you think?

[qarawlus]

The arrival times would definitely be an approximation to the trace, and not an exact match. I could immediately expect that we might miss some bursts if we average out inter arrival mean. I think this requires a deeper discussion on how we implement it. We should discuss it in the next meeting.

[stefanbschneider]

My suggestion is the following:

We start by creating a simple table (CSV file) that contains timestamps (in simulator time) and inter-arrival times that should be used starting at these times. We'll need a simple addition to read the table and schedule changes of the self.params.inter_arr_mean at the given times to the given values.

In the example here, we'd initially set self.params.inter_arr_mean=10 and directly schedule an event for t=50 at which we'd set self.params.inter_arr_mean=5 and immediately schedule the next event for t=100...

This would allow us to change traffic dynamically over time quite easily.

---

It's also a step into the right direction when we want to use (processed) traces later on.

The traces also include timestamps (eg, every 15min) with an ingress and egress node as well as the aggregated traffic volume that was sent between the pair within these 15min.

To handle these (later!), we'd additionally have to do the following:

• Allow setting different arrival times for different ingress nodes and ideally even for different services
• Convert the trace info into a table that can be processed by the simulator:
  • Convert times to suitable simulator timestamps
  • Re-interpret egress nodes as different SFCs? Or sum up all traffc per ingress
  • Calculate inter-arrival time for given traffic volume and fixed flow size

[stefanbschneider]

Closed by https://github.com/RealVNF/coordination-simulation/pull/93 for now. We'll tackle separate ingress/SFC arrival times and use of real traces later.

@qarawlus Could you prepare a Scenario09 with 1 ingress node, node cap 5 at all nodes and traffic that first gradually increases and then decreases again? The idea is that at first all flows could be processed at VNFs on a single node (at the ingress), but as traffic increases they need to be distributed over multiple nodes.

[stefanbschneider]

Didn't you also update the interface repo? I guess, you still have to make the PR to udpate it.