### Implementation of the simulation

Pycharm can not only run Python algorithms but also create GUIs. We use the pycharm-community-2019.1.1 editor to implement the algorithm and create a simulation environment.

We combine the algorithms from sections two and three to implement the QOGMP full-stream scheduling algorithm, which is implemented in the order Algorithm 2, Algorithm 1, and Algorithm 3. We perform a simplified simulation of the SDN network system.

The simplified network system is divided into two layers: the control layer and the data layer. The control layer controller has the function of receiving information from the data layer and the function of calculating the traffic scheduling scheme. The data layer has the function of data collection and stream transmission. Data transmission is allowed between the two layers.

In execution order, the specific functional design ideas are as follows: (1) Data layer data collection function: The data layer collects information from the network, including the switch *V*link *E* and link parameters (cost *VS*binding capacity *O*). (2) The function of the controller to receive information from the data layer: the controller gets the traffic view *g*(*V*, *E*, *VS*, *O*) returned by the data layer. (3) The function of the controller to calculate the flow planning scheme: we embed the traffic planning algorithm in the controller as the main algorithm of the controller. We take the views of the traffic *g*1(*V*, *E*, *VS*) , *g*2(*V*, *E*, *O*) and user requirements (including activity flow and delay tolerance) as inputs. After the execution of the main algorithm, the traffic scheduling scheme is produced. (4) Data layer stream transfer function: the data layer receives the schema generated by the controller and transmits the stream according to it (the task of the step is to calculate the transmission delay) .

### Tensile Link Verification Experiment

We conduct related experiments to verify the effectiveness of the tensile link. After implementing Algorithm 2, we record the amount of computation saved after applying the pull link algorithm to test whether extracting the pull link can significantly reduce the number of links.

We conduct experiments on 20 link graphs ( G=(G, E) ) with different link numbers. Assuming there is *not* knots in *V*the input format of the links graph (i.e. the contents of the dataset) is a ( n times n ) digital Matrix, ( e(i,j)=1 ) indicates that there is a link between the node *I* and knot *I*, ( e(i,j)=0 ) means that there is no link between the node *I* and knot *I*. The data used in the experiment is randomly generated. We record the number of links in the input and output link graphs (links between the same nodes are not recorded repeatedly), and the results are shown in Table 3 and Figure 2.

It can be obtained from Table 3 and Figure 2: After applying the pull-link algorithm, the saved computation amount is up to 77% of the original data amount, at least 50% of the original data amount and the recorded average. amount reached 66 percent.

Therefore, using the pull link algorithm can significantly reduce the number of links that need to be processed without affecting subsequent path selection results. This can save a large amount of calculations and improve the efficiency of the link weight calculation algorithm.

### Comparative experience

Currently, the traditional method with the best performance (delay and rescheduling rate) is the QoS-oriented global SDN traffic scheduling algorithm proposed in the literature.^{28.29}. The machine learning algorithm with the smallest delay is the global SDN multipath traffic scheduling algorithm based on reinforcement learning proposed in the literature.^{30}.

Compared to the algorithm proposed in the literature^{28.29}, the QOGMP algorithm takes into account multi-path scheduling and has a higher link utilization rate. It uses machine learning algorithms to speed up the calculation of weights, which is suitable for big data environments. On the other hand, the QOGMP algorithm has obvious advantages, so it is no longer verified by comparison experiments.

We evaluate the performance of QOGMP on the built simulation system. Performance evaluation indicators include delays and rescheduling rate. We compare QOGMP with the traffic planning algorithm which does not use pull links (i.e. implemented in the order of Algorithm 1 and Algorithm 3, below called pre-QOGMP) and the algorithm proposed by the literature^{30} (hereinafter referred to as GMPRL).

Delay here refers to the running time of the algorithm. We perform comparative experiments on the three algorithms. In order to reduce experimental error, each experiment should be measured multiple times to record the shortest running time.

For the delay indicator, the comparative experiment is performed on 20 different traffic views, and the experimental result is shown in Table 4.

Plot table 4 as Fig. 3. The analysis of FIG. 3 shows that: (1) the delay of QOGMP is always less than that of pre-QOGMP; (2) the delay of QOGMP is not much different from that of GMPRL.

It can be seen from the experimental results that QOGMP is better than pre-QOGMP and is almost compatible with GMPRL in terms of delay indicator. (1) Since QOGMP and GMPRL use machine learning algorithms, the delay of QOGMP is not much different from that of GMPRL; (2) QOGMP increases the extraction step of the pulling link, which leads to an increase in execution time. But at the same time, the introduction of the tensile link greatly saves the amount of calculation. Thus, QOGMP outperforms pre-QOGMP in terms of delay.

Since the three algorithms are all multi-path algorithms, the criteria used for the rescheduling judgment are the same, i.e. the sum of all path traffic in the solution generated by the algorithm is less than the service traffic or single path transmission delay exceeds the delay tolerance.

For the rescaling rate indicator, we run 20 sets of comparative experiments, each of which was performed on 20 to 100 different datasets. The experimental result is shown in Table 5.

Graphic table 5 as in Fig. 4. The analysis of FIG. 4 shows that: (1) The reprogramming rate of QOGMP is still not higher than GMPRL. In 17 out of 20 cases, the rescheduling rate of QOGMP is lower than that of GMPRL, and in 3 out of 20 cases, the rescheduling rate of QOGMP is the same as that of GMPRL. (2) The rescheduling rate of QOGMP is almost the same as that of pre-QOGMP, and the rescheduling rate of QOGMP is slightly higher than that of pre-QOGMP only in 1/20 cases.

It appears from the experimental results that the QOGMP is better than the GMPRL and is almost consistent with the pre-QOGMP in terms of the rescheduling rate indicator. (1) GMPRL ignores QoS requirements, which increases the likelihood that the traffic planning scheme is not suitable for service traffic, so QOGMP outperforms GMPRL in rescheduling rate; (2) Since the introduction of the tensile links will not have a big impact on the final scheme, therefore the QOGMP is almost identical to the pre-QOGMP in terms of the rescheduling rate.

In summary, compared to pre-QOGMP, QOGMP has a lower delay and almost the same reprogramming rate; Compared to GMPRL, QOGMP has a lower reprogramming rate and almost the same delay. Therefore, our proposed QOGMP is better than GMPRL and pre-QOGMP for delay and rescheduling rate indicators.