A congestion control scheme based on path recovery for smart grid communication

Abstract

In order to solve the problem that the original path forwarding traffic caused by congestion that cannot be recovered in time in Smart Grid Communication, a congestion control scheme RFCC (Router Forwarding Congestion Control) based on path recovery is proposed, which not only supports the receiving end combined with router nodes to relieve congestion, it can also solve the problem of low transmission performance caused by not being able to restore the original path in time after the traffic is transferred. Active queue management technology is used to detect congestion and notify downflow nodes (users and routers) in time, which trigger downflow users to adjust the request sending window and intermediate routers to transfer packets. In addition, the original path traffic is restored in time through the path recovery policy. Firstly, the path traffic is recovered according to the congestion mark carried by the subsequent content packets. Secondly, the transmission frequency of the probe packets is calculated according to the information such as the packet queue length of routers and the available bandwidth of the congested path, and the probe packets are periodically sent to the congested path, and the traffic is sent to the congested path in time. The alternate path is transferred back to the original path. This paper implements the scheme in NS-3, and extensive experiments show that the proposed scheme outperforms the comparison schemes, which not only higher and more stable throughput can be obtained, but also shorter and more stable transmission delay can be obtained. In addition, the optimal path transmission volume and link utilization are improved.

1 Introduction

With the development of grid communication, Internet applications are gradually changing from end-to-end communication to real-time content sharing and distribution [1]. Users are more concerned about how to get content quickly and easily than where to get content [2]. The traditional Internet paradigm was originally designed for host to host communication, but it exposed many problems (inefficient and lack of flexible data transmission, poor security and mobility) [3].

Smart Grid Communication is an emerging Power Grid architecture, changing the traditional power grid network communication model [4]. Information access in Smart Grid Communication is driven by the user, which requests data through the content name, and the routing node forwards the content according to the content name. This new model supports multicast content delivery, intra-network, multi-source caching, and multi-path forwarding [5, 6]. However, this new network architecture also complicates network congestion control because existing traditional congestion control solutions cannot be directly applied. In Smart Grid Communication, the concept of end-to-end connection is not applicable, because content blocks of the same content can be obtained from different servers or different node caches on the path to these servers [7, 8]. These different content sources will lead to different retrieval delays, and the requester cannot distinguish them. Therefore, the traditional detection based on RTT timeout has become an unreliable congestion detection index [9].

Traditional congestion control is based on an established connection between two endpoints. The sender detects congestion by measuring Round-Trip Time (RTT) or detecting packet loss, and then adjusts the sending rate accordingly. However, in Smart Grid Communication, the concept of end-to-end connection does not apply, because blocks of the same content can be obtained from different servers or from different node caches on the path to their servers. These different content sources can lead to different retrieval delays, and the users cannot distinguish them. Therefore, the traditional detection based on RTT timeout becomes an unreliable congestion detection indicator [9]. As for Smart Grid Communication congestion control research, many teams at home and abroad have proposed a series of effective solutions, which can be divided into the following types: receiver-based congestion control mechanism, router-based hop-by-hop congestion control mechanism.

ICP [10] is one of the receiver-based solution. It sets a Retransmission Timeout timer for each request and applies a traditional AIMD-based window adjustment algorithm, which does not consider the multi-source problem in Smart Grid Communication. Among the rate-based congestion control algorithms, CCTCP [11] maintains an RTO value for each source. It uses the “anticipated interests” mechanism to estimate the retransmission timeout to trigger the correct RTO value, which can better address the multi-source problems in Smart Grid Communication than ICP.

Hop-by-hop interest shaping mechanism (HoBHIS) [12] is one of the most eminent hop-by-hop-based method. In HoBHIS, the intermediate routers calculate the forwarding rate of request based on the queue occupancy and the available resources of each content flow. The receiver in HoBHIS only performs actions in response to a clear backpressure signal from the network.

Practical congestion control (PCON) [13] is an approach that develops an AQM scheme and the corresponding congestion control protocol. It has applied the CoDel AQM scheme, which monitors the sojourn time of content packets. In addition, it employs ECN to notify receivers of congestion.

Based on the above analysis, this paper proposes a congestion control scheme RFCC based on Active Queue Management (AQM), which can solve the problem of path recovery after congestion is relieved through intermediate node forwarding. The scheme detects congestion and generates marking information by deploying the improved AQM scheme ECN (Explicit Congestion Notification)-PIE in the intermediate routers and then, adds the marking information in the packets and forwards them to the users and downflow routers. Through adjusting request sending rate and diverts them to other alternative paths to control congestion. Moreover, for the transmission recovery problem of subsequent congested paths, we designed a double recovery mechanism. When the congested path is detected to work normally, all traffic is transferred from the sub-optimal link back to the original path in time, and the transmission continues on the optimal path.

2 Congestion control scheme based on path recovery strategy

2.1 Architecture

The scheme in this paper deploys ECN-PIE and path recovery strategy on each intermediate router. The overall workflow of the scheme is as follows. The intermediate router detects the congestion status of the node through ECN-PIE and decides whether to update the congestion information mark in the content, and then, further sends the content to the downflow node. The downflow router and the user control the congestion by changing the forwarding path and adjusting the sending rate, respectively. When the downflow node receives the upstream congestion mark information, it will divert all request to another alternative path, and the router may update the mark and transmit it further downflow. When the user receives the congestion mark information, it will adaptively adjust the request sending rate of the user.

In a dumbbell scenario, there is a User_1 connected to the network using the Smart Grid Communication protocol. R1, R2, and R3 are responsible for routing the user's request to the corresponding content source. User_1 requests content from Server_1 by using /Prefix/A. In a transmission process, according to the forwarding strategy, the optimal path is U1-R1-R2-S1. In addition, R1 is defined as a shunt node with multiple forwarding interfaces. When Server_1 sends the corresponding content packet, it will add the normal mark "00" to each content packet, and then, send the content to R2. ECN-PIE is deployed on R1, R2 and R3, respectively. For each router, ECN-PIE will periodically calculate the marking probability p according to the average queuing delay of content to decide whether to update the marking. When R2 calculates that p > 0, it means that the current node is congested, so the congestion mark in content needs to be updated. For each incoming content packet, if its mark is the normal mark "00", it will be updated with p probability. Mark "01" for mild congestion. R2 continues to send these content packets to the downflow shunt node R1. Once R1 receives the content packets with the mild congestion mark "01", it starts to perform the forwarding control of the intermediate node, that is, transfers all traffic from the current optimal path to the backup path (U1-R1-R3-S2). After that, if R1 receives a content packet carrying the normal mark "00" through the congested interface, it will retransfer the transferred traffic back to the original path. If R1 finds that there are no other optional diversion paths (other interfaces also receive the congestion mark "01"), R1 updates the mark to the heavy congestion mark "11" and forwards it downflow to User_1. When User_1 sees the content mark, it will take corresponding control actions to adjust the sending rate according to the congestion mark information.

2.2 ECN-PIE

ECN-PIE allows routers with large buffers to absorb burst traffic and keep queues small by detecting congestion before buffer overflow [14]. Specifically, ECN-PIE calculates the average queuing delay of content by measuring the average queue length of the current node within the cycle time (15 ms by default) and the average sending rate of request packets, then the marking probability p is calculated according to the current average queuing delay and the last average queuing delay.

This paper proposes four marks in ECN-PIE to feedback different congestion information to downstream routers and users under different congestion states. The four marks and their representative states are shown in Table 1. When preparing the corresponding content, the server will add the Normal Mark "00" (indicating no congestion) on each content. However, the Normal Mark "00" may be updated by downstream nodes. The principle of updating is that the lower the table item in Table 1, the higher the priority of updating. According to ECN-PIE, the probability that the Normal Mark is updated to the mild congestion mark is p (indicating the occurrence of mild congestion), and the probability that the Normal Mark is updated to the Null Mark "10" is 1-. When the content packet with Congestion Mark "01" is forwarded to the shunt node, it will select other available interfaces for forwarding the next traffic according to the received "01" content packet, and the user will appropriately reduce the window. In addition, if the shunt node finds that there are no available interfaces (all interfaces receive Congestion Mark "01"), the shunt node will generate a S-Congestion Mark "11" and choose to update it to a content to notify the user. In this scheme, when the content queue length exceeds 90% of the queue buffer, the transfer traffic is not enough to control the congestion. Therefore, the S-Congestion Mark "11" will be updated and transmitted to the downstream. The user receiving the S-Congestion Mark will greatly reduce the window size and quickly reduce the traffic which is injected into the network.

Table 1 Four marking information of ECN-PIE

According to ECN-PIE, every time a content packet arrives, it is necessary to probabilistic decide whether to update the mark of the content packet. The probability is updated periodically based on how far the current latency is away from the target value and whether the queuing latency is currently trending up or down. Specifically, ECN-PIE calculates the current queuing delay by measuring the average queue length and the average queue draining rate of each Data packet on its outgoing links within the cycle time (default is 15 ms), and then, the marking probability p is obtained by combining the current queuing delay and last queuing delay. Once calculating p > 0, the router is considered that the link is congested, and ECN-PIE will use p to update the mark of Data.

Furthermore, the content queuing latency can be obtained using direct measurements or using estimations calculated from the content queue length and the departure rate of Content packet. When the calculation result of p is 0 in the current period, it indicates that the node is not congested and the congestion mark remains Normal Mark unnecessary to update. If p > 0, Normal Mark needs to be updated as another mark due to congestion occurs. But due to the randomness of the update, even if congestion occurs, some content packets will not be updated to Congestion Mark and still keep Normal Mark. For Normal Mark, in order to distinguish two cases between congestion and no congestion, we update these content packets under congestion from Normal Mark to Null Mark with a probability of $1 - p$. For S-Congestion Mark, either node occurs severe congestion or shunt node cannot shift traffic, a router has to dynamically update it in any case.

2.3 Congestion control strategy

The congestion control strategy includes two control methods: mild congestion control and heavy congestion control to adapt to different congestion levels. In mild congestion control, when the shunt node receives the mild congestion mark "01", it relieves upstream congestion by diverting traffic [15, 16]. At the same time, when the user side receives the mild congestion mark "01", it will multiply the window by a smaller coefficient that can reduce the size of the sending window. However, if the shunt node cannot handle the current congestion through forwarding control, that is, there is no available interface or the content queue exceeds 90%. The shunt node will update the mark of a Content packet to the heavy congestion mark "11", and then, enter the heavy congestion control. For the heavy congestion mark "11", the shunt node and the user will take different control actions. On the one hand, the shunt node will stop the shunting and hand over all control to the user side. On the other hand, in order to alleviate network congestion, the user multiplies the window size by a larger coefficient to multiply the window size. The user's request sending window adjustment algorithm 1 is shown.

3 Path recovery strategy

The path recovery strategy judges whether to restore the optimal path according to the congestion mark information. When a congested interface is disabled, the congested interface can resume normal operation only when the interface receives the normal mark "00" again (indicating upstream congestion relief). However, if the congested interface continues to receive the Congestion Mark "01" or the Invalid mark "10", it indicates that the congestion status of the optimal path is not relieved at this time, and the interface will continue to be disabled.

After the shunt node receives the first Congestion Mark from an interface (the current optimal interface), the interface will be temporarily disabled, and it will not continue to forward requests from this interface. However, it will forward traffic to other standby interfaces. Usually, when a congested interface is temporarily disabled, the interface still receives some content requested before the disablement, which is called subsequent content packets. Therefore, the scheme in this paper firstly judges whether to reenable the congested interface according to the marking information carried by the subsequent content packets. When an interface receives Congestion Mark "01", the shunt node will start a timer of ${\text{Timer}}_{ - } 1$ for this interface. After that, whenever a new content arrives, the shunt node will use the sample ${\text{RTT}}$ to update the moving weighted average round-trip delay of ${\text{RTT}}_{{{\text{average}}}}$.

$${\text{RTT}}_{{{\text{average}}}} = \omega {\text{RTT}} + (1 - \omega ){\text{RTT}}_{{{\text{last}}}}$$

(1)

${\text{RTT}}_{{{\text{last}}}}$ is defined as the latest moving average round-trip delay, and ${\text{RTT}}$ is the sample ${\text{RTT}}$ of the current subsequent content packets. ω is a weight factor used for adjustment. Whenever the congested interface receives a subsequent content packet, it will update the value of the ${\text{RTT}}_{{{\text{average}}}}$ and then, record the value of the timer of the ${\text{Timer}}_{ - } 1$ at this time and compare it with ${\text{RTT}}_{{{\text{last}}}}$. If ${\text{RTT}}_{{{\text{average}}}}$ ≥ ${\text{Timer}}_{ - } {1}$, it means that the interface received subsequent packets within the latest ${\text{RTT}}$ time, then reset Timer_1 to 0. If ${\text{RTT}}_{{{\text{last}}}}$. If ${\text{RTT}}_{{{\text{last}}}}$ < ${\text{Timer}}_{ - } 1$, it means that the congested interface has not received subsequent content packets within the latest RTT. It is considered that all requests sent before the congested interface is disabled have been responded to, because the interface is temporarily disabled and no subsequent content packets will be returned after that.

Figure 1 is an example of recovering a congested path. For case A, the current optimal transmission path is R1-R2. After receiving Congestion Mark "01" from R2, R1 adjusts the forwarding interface to R3, and the transmission path becomes R1-R3. The congested interface connected to R3 starts Timer_1. If R1 receives a subsequent packet carrying "00" from R2, it means that the R2 congestion has disappeared, so the path R1-R2 is reenabled, and R1 turns off Timer_1 (case A to case B in Fig. 1). If R1 receives a content packet carrying "01" or "10" from R2, it indicates that the congestion of R2 has not been relieved at this time, and it needs to continue to be disabled, such as case C. In case D of Fig. 1. Since subsequent packets from R2 are exhausted and the interface is temporarily disabled without forwarding new requests, R1 will no longer receive packets from R2 after that. Considering this situation, R1 will start another timer ${\text{Timer}}_{ - } {2}$, and periodically and actively send probing request to R2 according to the time of Timer_2 to obtain the congestion status of the congested path.

Fig. 1

An Example of Recovering a Congested Path

In the above example, it can be seen that it is not enough to recover traffic only by subsequent content packets in the case of severe congestion. Therefore, actively sending probing requests to the congested interface is a necessary design for traffic recovery of congested paths. In this solution, when the subsequent content packets are exhausted, enough probe requests are actively sent to help the congested path recover traffic without increasing the congestion status of the congested path. In addition, in reference [17], the authors show that requests occupy a nonnegligible part of the link bandwidth, prompting this paper to consider the influence of request flow when sending probing requests. In order to make the probing request not aggravate the congestion state, the remaining available bandwidth of the congested link needs to be evenly distributed to each request flow and content flow. This article defines the sending frequency of the probing packet as T, the following will show how to obtain the frequency.

$$V_{i} (t) = \frac{B - u}{{N_{i} (t) + S*N_{d} (t)}}$$

(2)

In formula (2), $V_{i} (t)$ is the average request packet sending rate of content flow ${\text{i}}$ at time t. $B$ is the available link bandwidth, and ${\text{u}}$ is the link bandwidth that has been used during the time period of ($t - d$,$t$], so $B - {\text{u}}$ is defined as the current remaining available bandwidth. $N_{i} (t)$ indicates the number of request flows passing through the congested interface at time t, and $N{\text{d(t)}}$ indicates the number of content flows passing through. $S$ defined as the average size ratio of the content package and the request package, $L$ indicates the size of the content packet, and $H$ indicates the size of the request packet. For the average request packet sending rate of $V_{i} (t)$, use formula (4) to convert it into the corresponding average content packet sending rate of $V{\text{d}}(t)$.

$$S = \frac{L}{H}$$

(3)

$$V_{d} (t) = V_{i} (t)*S$$

(4)

In reference [14], the authors pointed out that the packet queue size varies with the queue exhaustion rate and the $RTT$ of the content flow. Therefore, it is necessary to further judge whether the request average sending rate of $V_{i} (t)$ obtained by formula (2) affects the congestion status of the upstream router. If the out-queue rate of packets of ${\text{avg\_drate}}$ is lower than the in-queue rate of $V_{i} (t)$, the content queue buffer of the upstream node will overflow within a congestion detection period, which can cause congestion. Therefore, if $V_{i} (t)$ ≤ ${\text{avg\_drate}}$, then $V_{i} (t)$ is available. Otherwise, it is further adjusted according to formula (5). The size of the congested path recovery strategy is adjusted by a weight factor of $V_{i} (t)$, and then, it needs to be judged again. Finally, the sending frequency of the probing request is calculated by formula (6). According to the average size of request packets, the unit of sending frequency is converted from bit/s to packets/s and rounded down.

$$V_{i} (t) = \alpha \frac{B - u}{{N_{i} (t) + S*N_{d} (t)}}$$

(5)

$$T = t\left\lfloor {\frac{L}{I(t)}} \right\rfloor$$

(6)

4 Experiment and performance evaluation

This paper uses the simulation platform NS-3 to implement the proposed congestion control mechanism, and compares it with other schemes.

4.1 Experimental setup

We implement the proposed congestion control methods RFCC based on path recovery strategy and ICP [10], using representative network typologies to evaluate and compare the two schemes. The following four indicators are used, which are network throughput, packet loss rate, queue length, and transmission delay time.

In this paper, the multi-source topology is shown in Fig. 2. All four users access the network through high-speed access links (100Mbps). Two users C1 and C2 share the same bottleneck link R1-R2. Both C1 (starting at 0 s) and C2 (starting at 1 s) go to the network. Server S1 requests 50 M content with a prefix of /Prefix/A. The specific link bandwidth and delay settings are shown in the figure. The other two users, C3 and C4, access the network through R2. C3 (starting at 5 s and stopping at 6 s) and C4 (starting at 8 s and stopping at 9th) send the prefix /Prefix/B to S1 at the specified time. The frequency is 5000 request packets per second.

Fig. 2

Multi-Source Network Topology

In addition, the size of the request packet is set to 40Bytes, the size of the content packet is set to 1024Bytes, and the queue length capacity of each router node in the topology is set to 200Pkts.

4.2 Analysis of simulation results

In the multi-source topology in Fig. 2, C1 starts to request content from S1 at 0 s, then another user C2 is launched 1 s later, and all users first request content from s2. Under this topology, this paper compares and analyzes the performance indicators of RFCC and ICP, such as throughput, packet loss rate, queue length, and average delay.

Figure 3 shows the result of comparing the C1, C2 and overall throughput of RFCC and ICP under the multi-source topology. It can be seen from the results that the over-all throughput of RFCC is higher than that of ICP. Due to the larger RTO time of RFCC, multiple invalid retransmissions are reduced, and more accurate congestion detection and adaptive path recovery control strategy are used. Therefore, the network utilization is higher and the overall throughput performance is also better. The ICP window algorithm adopts the AIMD algorithm. When the receiver receives the congestion information, it will immediately reduce the multiplicative effect. Therefore, the total throughput is jagged, and the frequency of congestion is relatively high. The RFCC uses adaptive node forwarding and the receiving. The congestion scheme of window adjustment, so the overall control effect is better. Even if the constant burst volume is increased in the 5 s and 8 s, good control can be achieved. Due to the path recovery strategy, it can restore traffic in a very short time and ensure network performance.

Fig. 3

a Throughput Comparison: RFCC. b Throughput Comparison: ICP

Figure 4 shows the result of comparing the packet loss rates of R2 and S2 for RFCC and ICP in the multi-source topology. It can be seen from the results that within the transmission time of 15 s, both C1 and C2 first request content from S2, so S2 and R2 are more prone to congestion, resulting in packet loss. RFCC is able to divert contents to an alternate path before the queue overflows, so there is no packet loss in multi-source scenarios. ICP can detect congestion and process it only after packet loss occurs. In addition, the AIMD algorithm is used in the ICP window, so the queue is often full. Therefore, packet loss is more likely to occur when all users request content from S2. As can be seen from Fig. 4, three packet losses occurred in R2 (2.3 s, 11.5 s, and 14.7 s, respectively), and two packet losses occurred in S2 (5.3 s, 8.2 s, respectively), so the window in the ICP will be reduced 5 times during 16 s, reducing network performance.

Fig. 4

a Comparison of R2 Packet Loss Rate. b Comparison of S2 Packet Loss Rate

Figure 5 shows the result of comparing the queue length variation of R2 and S2 in a multi-source multi-path topology with RFCC and ICP. In this topology, in order to better observe the queue changes, we set the queue capacity of each node to 200 Pkts. It can be seen that the RFCC does not exceed 200Pkts in both R2 and S2, that is, no packet loss occurs. When congestion occurs, request content mitigation from S1. S2 is congested. In the ICP, it can be seen that five packet losses have occurred, and the ICP will not request content from other servers, but only from S2, resulting in a jagged change in the queue length of S2 and easy packet loss. It can be seen in Fig. 5b the queue changes of S2, in the 5 s and 8 s, due to the addition of C3 and C4, the S2 queue is quickly filled up, and the RFCC transfers the traffic to S1 to avoid packet loss, while the ICP queue is full and overflowed, and packet loss occurs. Meanwhile, it can be seen from the results that both C1 and C2 in RFCC have lower transmission delay (68.69 ms and 67.08 ms) than that in ICP (74.11 ms and 71.15 ms). The transmission delay of each user (17.03 and 14.04) is also more stable than that in ICP (49.04 and 41.02).

Fig. 5

a R2 Queue Length Comparison. b S2 Queue Length Comparison

5 Conclusion

This paper proposes a congestion control solution RFCC based on path recovery for the forwarding of nodes in Smart Grid Communication that cannot recover the original path transfer traffic caused by congestion in time. RFCC combines user requesting rate adjustment and intermediate node forwarding and offloading congestion control scheme, which can not only coordinate the user as well as the router to dynamically relieve congestion, but also restore the optimal path traffic in time to ensure its transmission performance. Extensive experiments show that the throughput of RFCC is better than other comparison schemes, and more stable transmission delay and throughput can be obtained. In addition, the optimal path transmission volume and link utilization are improved.