## 4 Mechanisms and Optimizations
### Preference-Based Scheduling Strategies
* If a local CRN is found, the packet's destination IP is modified to the GN's IP corresponding to the SN and the packet is forwarded. The GN then returns a scheduling success response packet to the Client. * If no suitable CRN is found, and the SN has a superior node, the destination IP is modified to the IP of the root node in the scheduling domain, allowing exploration of potential CRNs in other scheduling domains. If there is no superior node, a scheduling failure response packet is directly returned to the Client. When the computing resource request has been scheduled, the SN first checks whether the available resource quantity of the destination CRN can meet the User's resource demands. \begin{table}
\begin{tabular}{l l} \hline \hline
**Variable** & **Definition** \\ \hline \(u_{i_{r}},u_{i_{m}},u_{i_{s}},u_{i_{b}}\) & The normalized utilization rates of CPU, memory, storage, and bandwidth for the \(i\)th CRN \\ \(N\) & The set of CRNs’ ordinal numbers \\ \(u_{i}\) & The mean of the normalized utilization rates for CPU, memory, storage, and bandwidth for the \(i\)th CRN \\ \(MaxNodeScore\) & The predefined maximum score for CRNs \\ \(s_{i}\) & The final score for the \(i\)th CRN \\ \(n\) & Total number of CRNs \\ \(m\) & Total number of Input Parameters \\ \(X_{n:\times m}\) & The original data matrix \\ \(i\) & CRN’s ordinal number \\ \(j\) & Input Parameter’s ordinal number \\ \(M\) & The set of input parameters’ ordinal numbers \\ \(X^{+}_{n:\times m}\) & The ”Benefit-Cost” adjusted data matrix \\ \(Z_{n:\times m}\) & The standardized data matrix \\ \(\omega_{j}\) & The weight for the \(j\)th input parameter \\ \(E_{j}\) & The information entropy for the \(j\)th input parameter \\ \(C\) & The set of the candidate CRNs \\ \(A\) & The set of all CRNs \\ \(n^{*}\) & Total number of candidate CRNs \\ \(p_{i}\) & The probability of selecting the \(i\)th candidate CRN \\ \(q_{i}\) & The cumulative probabilities for the \(i\)th candidate CRN \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Notation table. * If it can, the packet is forwarded to the GN corresponding to the SN and a scheduling success response packet is returned. * If it cannot, the SN performs a rescheduling based on the User's resource demands and preference parameters, modifying relevant fields in the packet accordingly. It is noteworthy that, as a distributed computing resource scheduling architecture, IPCRSA also adheres to the CAP theorem for distributed systems [52]. To enhance availability, IPCRSA, like many other distributed resource scheduling systems, follows the BASE principle, which guarantees only partition tolerance while striking a balance between availability and consistency. IPCRSA ensures only the eventual consistency of resource status information across SNs within the same scheduling domain, sacrificing strong consistency to improve the availability of resource scheduling. Consequently, it must grapple with the issue of resource contention resulting from the asynchronous nature of resource status information in the soft state. For instance, suppose a CRN has 16 CPU cores, 64 GB of memory, 1024 GB of storage, and 10 MB of available bandwidth. Three computing resource requests, A, B, and C, sequentially request resources of this node within the same resource status notification interval. The scheduling results based on the quota allocation of resources are illustrated in Figure 6. After allocating a fixed amount of resources to requests A and B, the remaining available resources are four CPU cores, 8 GB of memory, 256 GB of storage, and 1 MB of available bandwidth, which cannot satisfy the resource demand of request C.

In traditional Computing Network resource scheduling architectures, request C would remain pending, resulting in scheduling failure. However, in IPCRSA, the hierarchical scheduling structure accelerates the synchronization of resource status information, and the roulette-selection-based CRN selection mechanism ensures load balancing among CRNs.