1 Introduction

Named Data Networking (NDN) [1] is a proposal for the information-centric networking (ICN) concept that changes the network communication model from host-to-host packet delivery to fetching data by name. This novel communication model enables in-network caching, multi-source, and multipath content retrieving [2], which results in varying retrieval delays for content. However, consumers cannot distinguish between them, making traditional accurate Round-Trip Time (RTT) based congestion control schemes fail to be directly applied to NDN [3]. In order to be responsible for the robustness and stability of the network, it is critical to design an effective congestion control scheme for the NDN.

The existing NDN congestion control mechanisms have been designed from the aspects of consumers or routers. The consumer-based control mechanism [4], which is an adaptation of TCP behavior for NDN, controls the sending rate of Interest packets on the consumer side. This mechanism is able to aptly reduce the traffic volume, but can’t deal with severe congestion promptly. In hop-by-hop congestion control mechanism [5], routers promptly adjust the forwarding ratio of Interest packets to control the transfer rate of returning Data packets correspondingly. However, it cannot adjust the total amount of Data packets requested by consumers.

Therefore, the hybrid congestion control, a combination of the two mechanisms, has emerged rapidly, such as [6,7,8,9,10]. Nevertheless, the hybrid congestion control still has some deficiencies that need to be further perfected. Firstly, effectively cooperating consumer-based and router-based mechanisms, and avoiding the transport performance degradation caused by the repeated and excessive control still remains a problem that requires further research. Specifically, when the network has just encountered congestion, in common schemes, routers lower the transmission rate or switch forwarding paths for Interest packets, concurrently conveying congestion status to consumers. Once receiving the congestion indication, consumers promptly reduce the size of congestion window(cwnd). These two control processes are conducted sequentially, which probably reduce the consumer’s throughput extremely. Secondly, the suitable sub-path congestion control strategy for router of hybrid congestion control schemes also needs to be studied. In particular, as the utilization of an alternative path increasing, the RTT may become higher, as well as the occurrence of out-of-order deliveries. These phenomenon may cause a reduction in throughput.

Software Defined Network (SDN) architecture [11] is a set of innovative technologies that are applied to enable centralized control of network resources. It decouples the network control and forwarding functions, enabling flexible, manageable, cost-effective and adaptable network control of underlying infrastructure and network services. Its logical centralized management feature enables global network topology acquisition and dynamic network resource optimization.

Therefore, we take SDN as the “centralized” controller for NDN to tackle the above two issues in the hybrid congestion control mechanism. The proposed scheme is able to discern the congestion status of the network, and apply distinct control methods based on the states.

The contribution of this paper can be summarized as follows:

  • The forwarding and congestion control planes are decoupled, with SDN serving as the centralized controller for NDN, collaborating with routers to manage Interest packet flow in congested links.

  • A congestion detection method that supervises the status of the link is proposed. And a “Sieve" on the SDN controller for congestion state screening, ensuring cooperative congestion control between consumers and routers.

  • The proposed scheme effectively reducing network latency, promotes the stability of delay and ensures network throughput as well as fairness. Especially in multipath scenario1, compared to PCON, ndnSieve improves total throughput by 33.55%.

2 Related works

2.1 Consumer-based congestion control mechanism

Consumer-based congestion control mechanism evolves from traditional IP-based Internet, which controls the sending rate of Interest packets at consumer.

For instance, Carofiglio et al ’s ICP [12] mitigates congestion by implementing Additive Increase Multiplicative Decrease (AIMD) at the consumer end. In ICP, the congestion signal is the RTT, which ensures reliable data transmission by retransmitting the Interest packets in case of an RTT timeout. However, the NDN architecture has significant potential for multipath forwarding and managing multiple sources [13, 14], which makes ICP may be unable to work on NDN efficiently. In order to extend the ICP to multipath environments, the authors propose a multipath congestion control scheme, RAAQM [15], which maintains a unique Retransmission Timeout (RTO) value for each transmission path on the consumer side [14]. To address the issue of multiple sources, CCTCP [4] maintains a separate RTO value for each data source. Unlike implicit congestion control methods that rely on RTO and RTT as described above, a novel method to tackling the multi-source problem is to use explicit congestion detection and notification method [3]. ECP [16] monitors queue length of Data packets within the NDN router and notifies consumers of congestion levels, which adjusts their sending rate of Interest packets via Multiplicative Increase Additive Increase Multiplicative Decrease (MIAIMD) algorithm.

These congestion control schemes restrain the volume of Data packets by managing the delivery rate of Interest packets, reduceing the amount of in-flight Data packets of the network, thus addressing congestion issues from the source. However, the core problem of most existing consumer-based schemes is that they may not handle severe congestion promptly and timely, which may result in massive packet losses and increased latency [28].

2.2 Hop-by-hop congestion control mechanism

The stateful forwarding plane [17] of NDN enables routers to alleviate congestion at each hop [6], which have the potential to fully utilize new features such as in-network caching in NDN.

A classical hop-by-hop scheme is HoBHIS proposed in [18, 19], which allows NDN routers to shape the sending rate of Interest packets based on the queue occupancy of Data packets. Considering the interdependence between Interest packet and Data packet in opposite directions, Wang et al [20] designed an Interest shaping scheme to share the link bandwidth without requiring additional information exchange. In contrast to the previous Interest shaping schemes, [17] proposes a NACK feedback and multipath forwarding strategy. When upstream Interest packets are not forwarded due to congestion [3], a NACK is generated and returned to the downstream, which attempts to forward the Interest packets through other links [3].

Hop-by-hop congestion control can respond to congestion more promptly than consumer-based congestion control. However, pure hop-by-hop control schemes fail to reduce the total amount of Data packets entering the network, for it cannot adaptively and dynamically regulate the consumer’s Interest sending rate. This is impractical for actual deployment.

2.3 Hybrid congestion control mechanism

To leverage the advantages of both consumer and router control simultaneously, hybrid congestion control mechanism has emerged.

One early example of hybrid mechanism is HR-ICP [21], which combines two control methods: hop-by-hop Interest shaping and ICP [3], enables NDN routers and consumers to cope with congestion. In [22], another hybrid control scheme based on Interest shaping, named CHoPCoP, is proposed. This scheme regulates the forwarding rate only if the queue length exceeds the pre-set threshold [3], which makes CHoPCoP enables timely coping with congestion. However, if there is a persistent and severe congestion, using rate control on single path may not be sufficient to alleviate the congestion [3]. In this case, multipath forwarding could be a suitable method for distributing traffic and reducing congestion [3]. The most notable hybrid scheme based on multipath forwarding is PCON [6]. In PCON, downstream routers evenly distribute traffic to all alternative paths, and consumers resize the congestion window(cwnd), namely the maximum number of in-flight Interest packets allowed by a consumer.

However, in most hybrid congestion control schemes, both routers and consumers perform congestion control, triggering duplication and over-control, which may reduce consumer throughput. Secondly, the suitable sub-path congestion control strategies for router of hybrid congestion control schemes also needs to be studied. In particular, as the utilization of an alternative path increasing, the RTT may become higher, as well as the occurrence of out-of-order deliveries. These phenomenon may cause a reduction in throughput. Table 1 provides a visual representation of the literature discussed above.

Table 1 Schemes comparison
Full size table

2.4 Discussion

Consumer-based mechanism may not respond to severe congestion timely and promptly. Meanwhile, hop-by-hop mechanism fail to alleviate the total amount of Data packets being transmitted in the network. Hybrid congestion control can alleviate congestion in time by strategies that are deployed in the routers and the consumers.

However, the cooperation of consumers and routers is lacking consideration by many schemes. The concurrent control by both consumers and routers may results in duplication control and degraded data transmission performance. Moreover, the suitable sub-path congestion control method for router of hybrid congestion control schemes also needs to be studied. SDN, as a novel architecture, can achieve centralized management of network resources, which is applied to filter out different congestion states and impose consumer or router control methods on different states. Thus, SDN has received enormous attention. For example, in [23], a knapsack model is established, in which SDN controllers extract weight information, and optimize the forwarding process of flows based on Particle Swarm Optimization algorithm. [24] propose a framework called GreenVoIP. It utilizes the SDN to provide a global view of the entire network for integrated resource management, which can minimize the number of active devices, prevent overloading and provide service quality requirements. [25] propose a framework for data centers based on SDN to balance the load between servers and prevent overloading on a given server using PID algorithm. These schemes all optimize the traffic scheduling process significantly [26].

Therefore, we use SDN as a “centralized” controller for NDN to address the issues raised above, i.e., how to avoid duplicate control and how to utilize sub-paths.

3 Overview of ndnSieve

3.1 Architecture of ndnSieve

The architecture of the ndnSieve is depicted in Fig. 1, which consists of two elements, i.e., the routers and the SDN controller. The specific components of the router and controller is shown in Fig. 1.

Fig. 1
figure 1

Architecture of ndnSieve

Full size image

Besides the basic modules:Forwarding Information Base (FIB), Pending Interest Table (PIT) and Content Store (CS), these routers also implement a Local Information, a measure module that is used to calculate and cache link as well as queue information.

The centralized SDN controller consists of a southbound interface (SB), which interacts with the NDN router, a Topology Management module (TMM), a Global Information Cache(GIC), a congestion control method which is composed of Congestion Status Filter (CSF), and Cost Calculator.

The main responsibility of the TMM is to maintain a global topology of all routers and their links in the network for congestion control schemes to use. The CIC is used to store the local information obtained by the controller sending queries to the NDN router. The CSF is responsible for separating mild congestion signals from congestion signals and triggers the cost calculator to react. The Cost calculator is used to calculate the interface cost of the shunt router.

In general, the routers calculate the congestion status based on link capacity If congestion is detected, the routers send signals to the SDN controller, CSF will find the mild congestion signals and send them to Cost Calculator. After calculating, the SDN controller will pick out the shunt router and divert traffic to other interface to alleviate congestion. As for severe congestion, the router tags the Data packet with congestion mark. Once the marked Data packet arrive at consumer, the consumer will adjust the size of cwnd.

3.2 Transmission model

This subsection, the transmission models of ndnSieve are studied, including the network transmission model and the router transmission model, to address the parameter selection problem in the study of the congestion control mechanism.

The transmission model is shown in Fig. 2a. The network is modeled as a directed graph \({T = (V, E)}\), where V(T) is the set of network routers for T and E(T) is the set of links for T. Each router is linked to the SDN controller via the SB interface to upload information and receive commands. And Link(i, j) denotes the links in T, in which \({i,j\in V}\). The parameters in this model are described in detail next.

Fig. 2
figure 2

Transmission model

Full size image

The transmission model of the router is shown in Fig. 2b. The capacity of Link(i, j) in the network is restricted to \({{C}_{ij}>0}\). Denote the packet rate on Link(i, j) by \(x_{ij}^{n}\), namely the number of packets arriving at Link(i, j) per unit time. we likewise weigh the occupancy of the output queue in the router. The queue capacity of router I is restricted to \({{Q}_{I}>0}\), \({{q}_{I}}\) is used to denote the queue size on router I.

4 The process of ndnSieve

In this section, a complete ndnSieve process is shown in detail, including the congestion detection in each router, the controller-based path replacement working with the routers and the consumer rate adjustment that determines how to adapt its rate. And the controller-based path replacement is responsible for updating the priority of interface to move traffic from the congested link to the best available path.

4.1 Congestion detection

In this scheme, link utilization and queue occupancy are calculated to classify the network state into network free, mild congestion and severe congestion. The link utilization is calculated by the Local Information module of the router, as in Formula 1, to predict network congestion. \({{\beta }_{ij}}\) represents the utilization of the Link(i, j).

$$\begin{aligned} {{\beta }_{ij}}=\frac{{{x}_{ij}}}{{{C}_{ij}}} \end{aligned}$$
(1)

And the queue occupancy is also calculated, as in Formula 2, \({\varepsilon }_{mn}\) represents the queue occupancy of router N’s Mth interface.

$$\begin{aligned} {{\varepsilon }_{mn}}=\frac{{{q}_{M}}}{{{Q}_{N}}} \end{aligned}$$
(2)

With these two parameters, the router classifies the network state into three levels, which are network free state, mild congestion state, and severe congestion state, as shown in Table 2. The threshold value can be found in Table 3.

Table 2 Network state
Full size table
Table 3 Parameter setting
Full size table

When \({{\beta }_{ij}}>\text{th}_{1}\), the router sends a signal through the SB interface to notify the controller. The signal contains information about the sending router. When the network is severely busy, the router transmits Data packet with congestion label to inform the consumer.

Besides, routers are allowed to periodically report the costs for each interface (i.e.\({{\beta }_{ij}},{{\varepsilon }_{i}}\)) to the controller (Polling period Tp = 0.5 s).

4.2 The controller-based path replacement

When the controller receives a congestion signal from a router, the CSF acts like a sieve to separate link congestion from congestion signals, using the queue occupancy rate stored in the Global Information Cache, to trigger the Cost Calculator. This means that the controller only reacts to mild congestion to effectively promote the cooperation of control mechanisms of consumers and routers.

4.2.1 The algorithm of cost calculator

The Cost calculator module of the controller work with the router to implement path updates based on the Global Information Cache(GIC) to alleviate upstream congestion. And the Cost Calculator module control procedure is shown in Algorithm 1.

Firstly, by parsing the signal, the Cost calculator module gets the congested router ID, the sequence number in GIC of congested interface and select the prefix of traffic on congested links. Second, to shift traffic away from congestion paths, the Cost calculator module calls the function FindshuntNode(Topo) to find a shunt router. The shunt router is a router with multiple available interfaces downstream of a congested link. Third, based on the Global Information Cache, the function CostCalculation (LinkU, QueU) calculates the metric of each interface for the shunt router. Finally, the controller sends the calculated metric to the shunt router to control the path replacement process. The metric value is related to the selection of the optimal path. Interface corresponding to the lowest metric is considered most suitable for Interest packets forwarding. Since the metrics of each interface are periodically refreshed, once congestion occurs in the queue of the current optimal interface, its metric value increases. The router will then divert traffic to the new optimal interface. Such scheduling processes eventually converge to a stable state, achieving traffic balance.

Algorithm 1
figure a

The Algorithm of Cost Calculator

Full size image

4.2.2 Cost formulation

The link utilization is a good indicator of link congestion, so lower link utilization is preferred. SDN controllers also estimate queue occupancy in order to prevent data overflow. The interface metric is based on link utilization as well as queue occupancy. We have expressed the queue impact factor as an exponent in order to eliminate the impact of a zero queue occupancy on the cost.The final link metric is expressed in the following form:

$$\begin{aligned} {metric}_{faceM}=\underset{N\in V(G),ij\in E(G)}{\mathop {\max }}\,\beta _{ij} \times 10\times {{e}^{{{\varepsilon }_{mn}}}} \end{aligned}$$
(3)

4.3 The interest rate adjustment

As mentioned before, the router adds congestion marks to the Data packets returning to the consumer after severe congestion is detected. Once the Data packet with marks arrives at the consumer, the consumer has to manage the requesting rate. Similar to PCON, ndnSieve also employs a cwnd control method to adaptively adjust the Interest shaping rate, which results in limiting the entering traffic of the network.

The congestion control at the consumer end can restrict the incoming traffic into the network at the source. Upon receiving a Data packet with congestion mark, the consumer must decide to adjust the sending rate of Interest packets. To ensure stable throughput, the proposed scheme employs a smoother method to reduce the window size. Once a Data packet with congestion mark is received, the cwnd of Interest packets at the consumer decreases by 1 accordingly. If congestion alleviates afterward, the cwnd at the consumer increases by 1 for each received unmarked Data packet. The advantage of this method lies in the smooth variation of the cwnd, maintaining network traffic in a stable state, thus ensuring the transmission performance of the network, namely:

$$\begin{aligned} cwn{{d}_{k+1}}=cwn{{d}_{k}}+1 \end{aligned}$$
(4)
$$\begin{aligned} cwn{{d}_{k+1}}=cwn{{d}_{k}}-1 \end{aligned}$$
(5)

5 Analysis

5.1 Time complexity analysis

Time complexity refers to the computational efficiency of an algorithm, which can be expressed in terms of the number of basic operations performed by the algorithm.

As mentioned before, the congestion detection is executed by the routers locally. Thus, for any given router, congestion detection does not become more complex with the increasing scale of the network. Under the condition of excluding operations that are required during all congestion schemes (such as Data packets enqueuing and dequeuing), for each detection period, the router must calculate link utilization, queue occupancy for all available interfaces. Then, router evaluates each interface individually to determine if congestion has occurred, marks the Data packets accordingly, and sends notifications. Use \({{O}_{detection}}({{n}_{I}})\) to represent the executions times during detection for router I, then:

$$\begin{aligned} max [{{O}_{detection}}({{n}_{I}})]=4{{n}_{I}} \end{aligned}$$
(6)

\({{n}_{I}}\) is the number of available Data packets outgoing interfaces of router I; The maximum value is achieved only if congestion occurs on all \({{n}_{I}}\) interfaces.

Secondly, ignoring the time required for Global Information Cache (GIC) to store information, and the time for congestion notification propagation. Let \({{O}_{filter}}(M,{{n}_{I}})\) represent the number of times Congestion Status Filter (CSF) filters notification information. It can be found that:

$$\begin{aligned} max [{{O}_{filter}}(M,{{n}_{I}})]=\sum \limits _{I=1}^{I=M}{{{n}_{I}}} \end{aligned}$$
(7)

M denotes the number of routers in topology. The maximum value is achieved only if congestion occurs on all outgoing interfaces of Data packets for all routers.

If the number of mild congestion marks are \({{N}_{mc}}\), \({{N}_{mc}}\in [0,\sum \limits _{I=1}^{I=M}{{{n}_{I}}}]\). When the CSF sends signals to Cost Calculator, CSF will get the metrics, find corresponding shunt routers, and switch the forwarding Path. During that, complexity for finding the shunt router is dependent on the network topology, which is difficult to estimate. If \({{O}_{FSN}}\) denotes the complexity of finding shunt routers, \({{O}_{CCalculator}}({{N}_{mc}})\) denotes the complexity of Cost Calculate module, and \({{O}_{switch}}\) represents the complexity of path switching.Then:

$$\begin{aligned} {{O}_{CCalculator}}({{N}_{mc}})={{N}_{mc}}+{{O}_{FSN}}+{{O}_{switch}} \end{aligned}$$
(8)

Since congestion control at the consumer end is similar to the common schemes, its complexity can be ignored when being discussed. Then the time complexity of whole procedure is \({{O}_{detection}}({{n}_{I}})+{{O}_{filter}}(M,{{n}_{I}})+{{O}_{CCalculator}}({{N}_{mc}})\)

the \({{O}_{FSN}}\) is based on topology scale and the \({{O}_{switch}}\) is decided by the interfaces of the shunt router, which are Both positively correlated with the number of the routers. Thus, the complexity of ndnSieve is quite low, for it doesn’t need to operate on every Data packet that passes through. It also indicates that ndnSieve can perform better when the scale of network is small.

6 Evaluation

In this section, by using ns-3 based simulator, namely the ndnSIM [27], the performance of ndnSieve is analyzed and compared with PCON [6] and 2 state-of-the-art schemes called CoopCon [28] and FleCom [7]. The experiment results indicate that ndnSieve managed to reduce network delay, promote network total throughput and achieve relatively good fairness.

6.1 Simulation setup

The average throughput, delay, fairness, stability, and loss rate are the main indicators of our evaluation.

  • Throughput is a measurement of how many units of information networks are able to be handled for a given period, the unit of throughput in this section is Mbps.

  • Delay is the latency between the consumer issuing an Interest packet (the first time for a certain segment since the Interest packet may experience retransmission) and receiving the corresponding Data packet. the unit of delay in this section is millisecond.

  • The fairness is estimated by using the Jain Fairness Index [29].

  • The stability is demonstrated by standard deviation as well as box plots in this chapter.

  • The loss rate indicates the size of overflowed Data packtets in the scenario for a unit of time (Mbps).

To demonstrate the effectiveness of ndnSieve and its universality, we conducted experiments in a dumbbell scenario and two multipath scenarios. The experimental parameters are set as shown in Table 3.

Scenario 1 (Dumbbell Scenario): The scenario is shown in Fig 3a. There are two consumers C1 and C2, and two producers P1 and P2 in the system, which are connected by two routers R1 and R2. C1 requests Data packet with /prefix/A from P1, and C2 requests Data packet with /prefix/B from P2. The bandwidth of all links is 10 Mbps as well as link latency is 10 ms.

Fig. 3
figure 3

Experiments scenario

Full size image

Scenario 2 (Multipath Scenario1): A simplified but representative multipath scenario is adopted in Fig 3b. There is only one consumer C1 and two producers P1 and P2 in the system, and the system is connected through three routers R1, R2, and R3. C1 requests the Data packets hosted in P1 and P2 using the same prefix. The bandwidth of all the links are 10 Mbps, and the link latency is set to 10ms.

Scenario 3 (Multipath Scenario2): The network scenario for simulation consists of 9 devices, as shown in Fig 3c. C1 begins to send Interest packets to request Data packets from P1 at t = 0 s. When t = 1 s, C2 begins to send Interest packets to P2. At t = 2 s, C3 starts to send Interest packets to P3. Each Producer (P1, P2, P3) in this scenario possess Data packets with different prefix. The latency between routers and producers is 1ms, and the delay between R2-R3 is 15ms. The remaining links have the same delay of 10ms. All links possess the same bandwidth of 10Mbps.

6.2 Simulation result

6.2.1 Performance of dumbbell scenario

Figure 4 illustrates the total throughput of both consumers under different congestion control schemes. For PCON, the curve of the throughput jitters frequently. This is because the size of the cwnd decreases multiplicatively when the congestion occurs. The CoopCon and FleCom demonstrate great performance in terms of throughput metrics. For ndnSieve, the curve approaches the theoretical limit and exhibits only minor fluctuations. This is because ndnSieve adopts a more conservative window decrease method. Compared with PCON, the average total throughput of ndnSieve is 33.55% higher.

Fig. 4
figure 4

Comparison of total throughput for different schemes in dumbbell scenario

Full size image

Figure 5 demonstrates the average delay of each consumer employed with 4 different congestion control schemes. ndnSieve shows the lowest delay in both consumers. It indicates that ndnSieve is able to perform well in congestion control without multipath forwarding.

Fig. 5
figure 5

Comparison of average delay in dumbbell scenario

Full size image

Table 4 displays the standard deviation of delay for 4 schemes. The delay of ndnSieve is relatively stable, which means that the number of packets queued in the router fluctuates seldomly, and Fig. 6 is the delay boxplot of each consumer, which exhibits the same conclusion as that in Table 4 and Fig. 5.

Table 4 Standard deviation of delay in dumbbell scenario
Full size table
Fig. 6
figure 6

Comparison of delay boxplots for different schemes in dumbbell scenario

Full size image

This scenario employs Jain’s fairness index [29] to compare the fairness of the above schemes.

$$\begin{aligned} { Jain\_Fairness\_Index = \frac{{{{(\sum \nolimits _{i = 1}^N {{x_i}} )}^2}}}{{N\sum \nolimits _{i = 1}^N {{x_i}^2} }}} \end{aligned}$$
(9)

The range of fairness index values is from 1/N to 1, where a value closer to 1 indicates a fairer allocation. Table 5 demonstrates the average Jain Fairness Index of each scheme. ndnSieve and FleCom both exhibit the highest degree of fairness, which indicates the bandwidth of R1-R2 is almost consumed by 2 consumers equally.

Table 5 Average Jain Fairness Index for different schemes in dumbbell scenario
Full size table

Figure 7 illustrates the loss rate of each scheme. The packet loss rate is 0 for all schemes, which can be concluded that in addressing packet loss issues, all four schemes are relatively effective.

Fig. 7
figure 7

Comparison of Loss rate in dumbbell scenario

Full size image

6.2.2 Performance of multipath scenario1

Figure 8 demonstrates the average throughput of each protocol. PCON has the lowest and most unstable total throughput, as the cwnd decreases significantly when encountering congestion. While ndnSieve diverts the traffic to other available links after mild congestion is detected, that is the reason for the minor fluctuations observed at 1 s in the plot. The throughput of CoopCon and FleCom fluctuate around 10 Mbps. Nevertheless, compared with CoopCon, FleCom is able to dynamically calculate the adjustive size of cwnd on the level of network congestion, which results in higher and steadier throughput. Overall, the effectiveness of the FleCom and ndnSieve is comparable.

Fig. 8
figure 8

Comparison of total throughput for different schemes in multipath scenario1

Full size image

Figure 9 illustrates the throughput variations of the two interfaces of Router 1. The interface 260 corresponds to the R1–R2 link while interface 261 corresponds to the R1–R3 link. The ndnSieve diverts the traffic from interface 260 to 261 at 1 s, which ensures that Data packets are always transmitted through the shortest path in terms of latency. For PCON, the throughput of interface 260 remains at a high level, while that of interface 261 consistently stays low. The reason for this phenomenon is that PCON transfers 2% of the traffic from congested link to other available interfaces once received a Data packet with congestion mark. CoopCon and FleCom don’t effectively utilize interface 261 for transmission, as CoopCon only conducts traffic redirection when severe congestion occurs. In FleCom, congestion detection takes into account the trend of the sojourn time of Data packets within routers changes, which contributes to congestion avoidance. Thus, only a small amount of congestion occurs, and few Data packets are forwarded to interface 261 due to congestion. Overall, ndnSieve offers more flexible path switching while also ensuring relatively high throughput.

Fig. 9
figure 9

Comparison of the forwarding ratio for the two interfaces of R1 in multipath scenario1

Full size image

Figure 10 demonstrates the average delay with different congestion control schemes in multipath scenario1, in which ndnSieve exhibits the best performance. As ndnSieve considers the global traffic situation, and always uses the path with lowest delay for Data packets forwarding.

Fig. 10
figure 10

Comparison of average delay in multipath scenario1

Full size image

Table 6 displays the standard deviation of delay for 4 schemes. Due to the path switching, the standard deviation of delay for ndnSieve is slightly higher than that of FleCom. The statistics indicate ndnSieve and FleCom exhibit similar and excellent standard deviations of delay, both significantly less than that of CoopCon and PCON.

Table 6 Standard deviation of delay in multipath scenario1
Full size table

Figure 11 provides a better visualization for stability of delay. The box of FleCom and ndnSieve is extremely narrow, approximating a line, which indicates these 2 schemes both have great latency stability.

Fig. 11
figure 11

Comparison of delay boxplots for different schemes in multipath scenario1

Full size image

Figure 12 is the plot of packet loss rate, there are no packet loss detected during experiment, which indicates that the queue in the router is not experiencing packet overflow.

Fig. 12
figure 12

Comparison of Loss rate in multipath scenario1

Full size image

6.2.3 Performance of multipath scenario2

Figure 13 illustrates the instantaneous throughput of consumers deployed with 4 different congestion control schemes. ndnSieve maintains a consistent high throughput, as the effective collaboration between the consumers and routers of ndnSieve. At 1 s and 2 s, consumer 2 and consumer 3 are activated respectively, when 4.1 s, congestion is detected and path switching function is triggered, which causes minor jitters.

Fig. 13
figure 13

Comparison of total throughput for different schemes in multipath scenario2

Full size image

For PCON, the total throughput gradually increases during fluctuation processes. The reason for fluctuations of throughput lies in the fact that once congestion occurs, consumers deployed PCON will multiplicatively decrease their cwnd, leading to a diminution in throughput. The reason for the gradual increase in total throughput is once routers detect congestion, they will divert traffic to alternative links. Thus, the utilization of the alternative link gradually increases over time. The combined effect of these two reasons results in the characteristic observed in the total throughput of Fig. 13b. For CoopCon, the consumers gradually adjust the size of cwnd, routers do not experience severe congestion. Therefore, traffic does not shift to alternative link, resulting in its lower throughput. Compared with CoopCon, whenever congestion occurs, FleCom adjusts the forwarding path, enabling itself to fully utilize the bandwidth of multiple links, which results in the maximum throughput of FleCom is nearly twice that of CoopCon. Overall, ndnSieve demonstrates noticeably stronger stability, its performance of throughput is also excellent.

Figure 14 illustrates the throughput of R1’s 2 interfaces. The interface 260 corresponds to the R1-R2 link while interface 261 corresponds to the R1-R3 link. Among subplots, Fig. 14a, b, d, the ndnSieve demonstrates remarkable fairness. For CoopCon, the routers do not forward the Data packets to alternative link, which lead to relatively less fairness. This is because the consumers deployed with CoopCon are gradually adjusting its cwnd, avoiding the severe congestion and no transfer takes place. Table 7 shows the Jain Fairness Index of throughput, where FleCom and ndnSieve have relatively high level of fairness.

Fig. 14
figure 14

Comparison of the forwarding ratio for the two interfaces of R1 in multipath scenario2

Full size image
Table 7 Average Jain Fairness Index in multipath scenario2
Full size table

Figure 15 demonstrates the average delay of each consumer with different schemes. ndnSieve shows the lowest delay in both consumer1 and consumer2, since ndnSieve selects specific content for path replacement and considers the global traffic situation.

Fig. 15
figure 15

Comparison of average delay of each consumer for different schemes in multipath scenario2

Full size image

Figure 16 is the boxplot of delay for each consumer. The box representing ndnSieve is consistently narrow among 3 subplots, which implies that the delay of ndnSieve is relatively stable. The results displayed in Table 8 demonstrate ndnSieve achieve relatively excellent performance.

Fig. 16
figure 16

Comparison of boxplot of delay in multipath scenario2

Full size image
Table 8 Standard deviation of delay in multipath scenario2
Full size table

Figure 17 is the plot of packet loss rate, there are still no packet loss detected during experiment, which implies all schemes are effective in suppressing packet dropping.

Fig. 17
figure 17

Comparison of Loss rate in multipath scenario2

Full size image

7 Conclusion and future work

In this paper, using SDN, a novel NDN hybrid congestion control scheme is proposed to alleviate network congestion and improve network stability. Simulation results show that, ndnSieve is able to effectively reduce network latency, promotes the stability of delay and ensure network throughput as well as fairness. In particular, in the dumbbell scenario, the Jain Fairness Index of ndnSieve is 1.00, which is one of the highest among 4 schemes. And in the multipath scenario1, the total throughput of consumers deployed with ndnSieve is 33.55% higher than that of consumers deployed with PCON.

In the future, we intend to distinguish the priority of various flow and take differentiated processing based on the priority of Data packets. The retransmission timeout method should also be considered to enhance the robustness of ndnSieve.