# Two-Level Congestion Control Mechanism (2 LCCM) for Information-Centric Networking
## 3 Design
### Heavy Congestion and Light Congestion  
As mentioned above, when the heavy congestion happens during a chunk transmission, a replacement replica can be reselected to continue the transmission, while under light congestion, the requested data delivery rate is adjusted by a congestion control algorithm.  
In the related work in Section 2, we mentioned that the concepts of heavy and light congestion are also found in R2T [28] and ConTug [24]. R2T uses an abnormally long RTT as a light congestion signal and performs congestion avoidance by hop-by-hop interest shaping, and determines heavy congestion when the intermediate network nodes display feedback congestion information up to a certain level. The receiver then immediately reduces the requested transmission rate. ConTug uses the RTT variation similar to the TCP Vegas [35] algorithm as a light congestion indicator. The difference between the estimated RTT value and the actual value is converted into the transmission rate difference, so the network can be judged to have light congestion when the difference exceeds a certain range, and the congestion window decreases linearly. ConTug uses a timeout of receiving packet as the heavy congestion indicator, and the congestion window is halved. In the classical TCP Reno [29] algorithm, which uses AIMD for congestion avoidance, TCP considers the network to be slightly congested based on three consecutive ACKs and performs fast retransmission and fast recovery algorithms, and then adjusts the congestion window to half of the window threshold. Thus, we can see that different levels of congestion affect the magnitude of congestion window adjustment in R2T, ConTug, and TCP. For our method proposed in this paper, when the link is under light congestion, the congestion window is also adjusted by adjusting the congestion window and thus affecting the request delivery rate. However, if the link is under heavy congestion, the decision of replica switching is executed according to the current transmission situation.  
In order to avoid misjudgment of congestion due to random packet loss from the network physical devices, we do not simply judge the degree of congestion by packet loss, but by a mixture of the number of packet losses and RTT fluctuations, as shown in Equations (1)-(3).  
\[\text{PacketLossFlag}= \left\{\begin{array}{c}1,\text{ if }\text{NUMloss }>\text{ k}\\ 0,\text{ else}\end{array}\right. \tag{1}\] \[\text{RttChangeFlag}= \left\{\begin{array}{c}1,\text{ if }\frac{\text{RTT}_{\text{current}}-\text{RTT}_{\text{base}}}{ \text{RTT}_{\text{base}}}>\text{ }\delta\\ 0,\text{ else}\end{array}\right.\] (2) \[\text{\emph{CongestionFlag}}= \text{\emph{LossPacketFlag}}\text{\emph{1 RttChangeFlag}} \tag{3}\]  
where the number of consecutive packet loss \(\text{NUM}_{\text{loss}}\) is obtained by counting the number of packet loss due to timeout over a period of time, \(\text{RTT}_{\text{current}}\) is the current RTT value maintained, and \(\text{RTT}_{\text{base}}\) is the minimum RTT value within a certain time frame. If the _CongestionFlag_ result is 1, the link state is judged to be under heavy congestion, otherwise, it is under light congestion. In other words, when the number of packet losses reaches a certain number or the RTT fluctuates widely, the current link is judged to be under heavy congestion.