Keywords

Ethernet congestion control; Quantum Congestion Notification; QCN; Reaction Point or RP algorithm; Control Point or CP Algorithm; QCN Stability Analysis; IEEE802.1Qau

8.1 Introduction

Ethernet is the most prevalent Layer 2 technology used in Internet Protocol (IP) networks; it is almost as old as IP itself. Traditionally, Ethernet left the job of congestion control to IP while providing basic medium access control (its original purpose in shared media links) and later Layer 2 bridging and switching functionalities. This state of affairs started to change in the past 10 to 15 years as the use of Ethernet expanded to wider domains. One of these domains is data center networking, and Chapter 7 discusses server-to-server networking in DCNs using Ethernet as the switching fabric with TCP running on top.

An aspect of data center networks (DCNs) not discussed in Chapter 7 is that of communications between the servers and storage devices. The networks that are used to interconnect them together are known as Storage Area Networks (SANs). Fiber Channel (FC) is a Layer 1–2 high-speed point-to-point interconnect technology that is used to create SANs. A very strong requirement in SAN networks is that the packet drop rate caused by buffer overflows should be zero. FC networks use a hop-by-hop congestion control method to accomplish this goal, whereby a node that is running out of buffers sends a signal to the node upstream from it to stop it from transmitting.

Link speeds in FC increased over time, but they were not able to keep pace with the more rapid increases in Ethernet link speeds that have gone from 1 to 10 Gbps and then to 100 Gbps in the past decade and a half. In addition, Ethernet adaptors and switches come at a lower cost because of their wider adoption in the industry. Motivated by these considerations, the industry created a FC over Ethernet (FCoE) standard, in which Ethernet is used as the Layer 1–2 substrate in SANs. However, using TCP as the congestion control mechanism will not work in an FCoE SAN because TCP does drop packets during the course of its normal operation. As a result, an effort was started in the Institute of Electrical and Electronics Engineers (IEEE) 802.2 Standards Body to make modifications to Ethernet so that it is suitable for deployment in a SAN (or a DCN in general), called Data Center Bridging (DCB) [1]. One of the outcomes of this effort is a congestion control protocol called IEEE 802.1Qau [2], also known as Quantum Congestion Notification (QCN), which operates at the Ethernet layer and aims to satisfy the special requirements in DCB networks [3].

There is more design latitude in the design of QCN compared with TCP because Ethernet provides 6 bits of congestion feedback (as opposed to 1 bit in TCP), and the QCN design takes advantage of this by implementing a proportional-integral (PI) controller at the Ethernet switch, which we know to be superior than Random Early Detection (RED) controllers. The QCN increase–decrease protocol has some novel features described in Section 8.4. Alizadeh et al. [4] carried out a comprehensive control theoretic analysis of the fluid model of the QCN algorithm that forms the subject matter of Section 8.5.

8.2 Differences between Switched Ethernet and IP Networks

Alizadeh et al. listed the following contrasts between switched Ethernet networks and IP networks [3]. We already mentioned one of them in the Introduction (i.e., packets should not be dropped); the others are:

The next three differences are more specific to DCNs in general and served as constraints in the design of a transport level congestion control algorithm as well:

8.3 Objectives of the Quantum Congestion Notification Algorithm

The QCN algorithm was designed based on all the learning from the design and modeling of TCP congestion control algorithms over the previous 2 decades. As a result, it incorporates features that keep it from falling into performance and stability traps that TCP often runs into. Some of the objectives that it seeks to satisfy include the following:

8.4 Quantum Congestion Notification Algorithm Description

The algorithm is composed of two main parts: Switch or Control Point (CP) Dynamics and Rate Limiter or Reaction Point (RP) Dynamics.

8.4.1 The Control Point or CP Algorithm

The CP algorithm runs at the network nodes, and its objective is to maintain the node’s buffer occupancy at the operating point b_eq (Figure 8.1). It computes a congestion measure F_b and randomly samples an incoming packet with a probability that that depends on the severity of the congestion (Figure 8.2). It sends the value of F_b back to the source of the sampled packet after quantizing it to 6 bits.

Define the following:

b: Value of the current queue length

b_old: Value of the buffer occupancy when the last feedback message was generated

b_off:=b−b_eq

b_d:=b−b_old

Then F_b is given by the formula:

$F_b=b_{off}+w{b}_d$ (1)

(1)

where w is a non-negative constant, set equal to 2 for the baseline implementation. Note that equation 1 is basically the PI Active Queue Management AQM controller from Chapter 3. The first term on the RHS is the offset from the target operating point (i.e., the buffer oversubscription), and the second term is proportional to the rate at which the queue size is changing. As per equation 55 in Chapter 3, this is proportional to the difference between the link capacity and the total traffic rate flowing through the link (i.e., the link oversubscription).

When $F_b<0$, there is no congestion, and no feedback messages are sent. When $F_b\ge 0$, then either the buffers or the link or both are oversubscribed, and control action needs to be taken. An incoming packet is sampled with probability $p_s=\varphi (F_b)$ (see Figure 8.2), and if p_s=1 and $F_b\ge 0$, then a congestion feedback message is sent back to the source.

8.4.2 The Reaction Point or RP Algorithm

The RP algorithm runs at the end systems and controls the rate at which Ethernet packets are transmitted in to the network. Unlike TCP, the RP algorithm does not get positive ACKs from the network and hence needs alternative mechanisms for increasing its sending rate. Define the following:

Current rate (R_C): The transmission rate of the source

Target rate (R_T): The transmission rate of the source just before the arrival of the last feedback message

Byte counter: A counter at the RP for counting transmitted bytes; it is used to time rate increases

Timer: A clock at the RP that is used for timing rate increases. It allows the source to rapidly increase its sending rate from a low value when a lot of bandwidth becomes available.

Initially assuming only the Byte Counter is available, RP uses the following rules for increasing and decreasing its rate.

8.4.2.1 Rate Decreases

A rate decrease is only done when a feedback message is received, and in this case, CR and TR are updates as follows:

$R_T\leftarrow R_C$ (2)

(2)

$R_C\leftarrow R_C(1-G_d|F_b|)$ (3)

(3)

The constant G_d is chosen so that $G_d\left|F_{b\max }\right|=\frac{1}{2}$ (i.e., the rate can decrease by at most 50%). Because only 6 bits are available for feedback, it follows that $F_{b_{\max }}=64$, so that $G_d=1/128$ accomplishes this objective.

8.4.2.2 Rate Increases

Rate Increase is done in two phases: Fast Recovery and Active Increase (Figure 8.3)

Fast Recovery (FR): The source enters the FR state immediately after a rate decrease event, at which point the Byte Counter is reset. FR consists of 5 cycles, in each of which 150 Kbytes of data are transmitted (100 packets of 1500 bytes each), as counted by the Byte Counter. At the end of each cycle, R_T remains unchanged, and R_C is updated as follows:

$R_C\leftarrow \frac{R_C+R_T}{2}$ (4)

(4)

The rationale behind this rule is if the source is able to transmit 100 packets without receiving another Rate Decrease message (which are sent by the CP once every 100 packets on the average since p_s=0.01), then it can conclude that the CP is uncongested, and therefore it increases its rate. Note that FR is similar to the way in which a Binary Increase Congestion Control (BIC) TCP source increases its window size after a packet drop (see Chapter 5). This mechanism was discovered independently by Alizadeh et al. [3].

Active Increase (AI): After 5 cycles of FR, the source enters the AI state, where it probes for extra bandwidth. AI consists of multiple cycles of 50 packets each. During this phase, R_T and R_C are updates as follows:

$R_T\leftarrow R_T+R_{AI}$ (5)

(5)

$R_C\leftarrow \frac{R_C+R_T}{2}$ (6)

(6)

where R_AI is a constant, set to 5 mbps by default.

When R_C is extremely small after a rate decrease, then the time required to send out 150 Kbyes can be excessive. To speed this up, the source also uses a Timer, which is used as follows: The Timer is reset when the rate decrease message arrives. The source then enters FR and counts out 5 cycles of T ms duration (T=10 ms in the baseline implementation), and in the AI state, each cycle is T/2 ms long.

• In the AI state, the R_C is updated when either the Bye Counter or the Timer completes a cycle.

• The source is in the AI state if and only if either the Byte Counter or the Timer is in the AI state. In this case, when either completes a cycle, R_T and R_C are updated according to equations 5 and 6.

• The source is in the Hyper-Active Increase (HAI) state if both the Bye Counter and the Timer are in AI. In this case, at the completion of the i^th Byte Counter or Timer cycle, R_T and R_C are updated as follows:

$R_T\leftarrow R_T+i{R}_{HAI}$ (7)

(7)

$R_C\leftarrow \frac{R_C+R_T}{2}$ (8)

(8)

where R_HAI is set to 50 mbps in the baseline.

8.5 Quantum Congestion Notification Stability Analysis

The stability analysis is done on a simplified model of the type shown in Chapter 3, Figure 3.2, with N connections with the same round trip latency, passing through a single bottleneck node with capacity C [4]. Following the usual recipe, we will first write down the differential equations in the fluid limit and then linearize them around an operating point, which allows us to analyze their stability using tools such as the Nyquist stability criterion. We will assume that p_s is fixed at p_s=1% in this section to simplify the analysis. Also, all connections are assumed to have the same round trip latency equal to $\tau$ seconds.

In contrast to other congestion control protocols, two variables R_C(t) and R_T(t), are needed to describe the source behavior:

$\frac{d{R}_C}{dt}=-G_d{F}_b(t-\tau )R_C(t)R_C(t-\tau )p_r(t-\tau )+\left(\frac{R_T(t)-R_C(t)}{2}\right)\frac{R_C(t-\tau )p_r(t-\tau )}{{(1-p_r(t-\tau ))}^{-100}-1}$ (9)

(9)

$\frac{d{R}_T}{dt}=-(R_T(t)-R_C(t))R_C(t-\tau )p_r(t-\tau )+R_{AI}{R}_C(t-\tau )\frac{p_r(t-\tau )}{{(1-p_r(t-\tau ))}^{-500}-1}$ (10)

(10)

$\frac{db}{dt}=\{\begin{array}{lll}N{R}_C(t)-C\hfill & if\hfill & b(t)>0\hfill \\ \max \{N{R}_C(t)-C,0\}\hfill & if\hfill & b(t)=0\hfill \end{array}$ (11)

(11)

$F_b(t)=b(t)-b_{eq}+\frac{w}{C{p}_s}(N{R}_C(t)-C)$ (12)

(12)

$p_r(t)=p_s{1}_{[F_b(t)>0]}$ (13)

(13)

To justify the negative first terms in equations 9 and 10, note that $R_C(t-\tau )p_r(t-\tau )$ is the rate at which negative ACKs are arriving at the source. Each of these causes R_C to decrease by $R_C(t)G_d{F}_b(t-\tau )$ and RT to decrease by $R_T(t)-R_C(t)$.

To derive the positive second term in equation 9, consider the following: The rate R_C is increased on the transmission of 150 Kbytes, or 100 packets of 1500 bytes each, if no negative ACK is received in the interim. The change in R_C when this happens is given by

$\begin{array}{ll}\mathrm{\Delta }{R}_C(t)\hfill & =\frac{R_C(t)+R_T(t)}{2}-R_C(t)\hfill \\ \hfill & =\frac{R_T(t)-R_C(t)}{2}\hfill \end{array}$

To compute the rate at which the R_C rate increase events occur, consider the Markov chain in Figure 8.4: It is in state k if k packets have been transmitted back to back without the receipt of a single negative ACK. Starting from state 0, in general, the system may undergo several cycles where it returns back to state 0 before it finally transmits 100 packets back to back and gets to state 100. It can be shown that the average number of packets transmitted to get to state 100 when starting from state 0, is given by

$E_0(T_{100})=\frac{{(1-p_r)}^{-100}-1}{p_r}$ (14)

(14)

This can be derived as follows: Define $u_i=E_i(T_{100}),0\le i\le 99$ as the average number of packets transmitted to get to state 100 when starting from state i. Based on the Markov chain in Figure 8.4, the sequence u_i satisfies the following set of equations (with q_r=1−p_r):

$\begin{array}{l}{u}_0=(1+u_1)q_r+(1+u_0)p_r\hfill \\ u_1=(1+u_2)q_r+(1+u_0)p_r\hfill \\ \cdots \hfill \\ u_{98}=(1+u_{99})q_r+(1+u_0)p_r\hfill \\ u_{99}=q_r+(1+u_0)p_r\hfill \end{array}$

This set of equations can be solved recursively for u₀, and results in equation 14.

Because the average time between packet transmissions is given by $\frac{1}{R_C(t-\tau )}$, it follows that the average time between increase events is given by

$\mathrm{\Delta }T=\frac{{(1-p_r(t-\tau ))}^{-100}-1}{R_C(t-\tau )p_r(t-\tau )}$ (15)

(15)

The second term on the RHS of equation 9 follows by dividing equation 14 by equation 15. The second term on the RHS of equation 10 is derived using similar considerations. In this case, R_T increments by R_AI when 500 packets are transmitted back to back without returning to state 0, which results in a Markov chain just like that in Figure 8.4, except that it extends up to state 500.

We now compute the equilibrium values of the variables in equations 9 to 13. In equilibrium, we replace p_r by p_s throughout.

Define

$\eta (p_s)=\frac{p_s}{{(1-p_s)}^{-100}-1},\zeta (p_s)=\frac{p_s}{{(1-p_s)}^{-500}-1}$

The fluid flow model in equations 9 to 13 has the following equilibrium points:

$R_C^{*}=\frac{C}{N}$ (16)

(16)

Equation 16 follows by setting db/dt=0 in equation 11.

$R_T^{*}=\frac{C}{N}+\frac{\varsigma (p_s)R_{AI}}{p_s}$ (17)

(17)

Equation 17 follows by setting dR_T/dt=0 in equation 10.

Note that from equation 12, it follows that

$b^{*}=b_{eq}+F_b^{*}$ (18)

(18)

and equation 9 implies that

$F_b^{*}=\frac{(R_T^{*}-R_C^{*})}{2R_C^{*}({(1-p_s)}^{-100}-1}$ (19)

(19)

Substituting for $R_C^{*}$ and $R_T^{*}$ from equations 16 and 17 into equation 19, we finally obtain

$b^{*}=b_{eq}+\frac{\eta (p_s)\varsigma (p_s)N{R}_{AI}}{2p_s^2{G}_{d}C}$ (20)

(20)

We now proceed to linearize the equations 9 to 11 around the equilibrium points $(R_C^{*},R_T^{*},b^{*})$. Define the following deltas around the equilibrium:

$\delta R_C(t)=R_C(t)-R_C^{*},\delta R_T(t)=R_T(t)-R_T^{*},\delta b(t)=b(t)-b^{*}$

Using the Linearization procedure described in Appendix 3.A of Chapter 3, it can be shown that the following equations result:

$\frac{d\delta R_C}{dt}=-a_1\delta R_C(t)+a_2\delta R_T(t)-a_3\delta R_C(t-\tau )-a_4\delta b(t-\tau )$ (21)

(21)

$\frac{d\delta R_T}{dt}=g\delta R_C(t)-g\delta R_T(t)$ (22)

(22)

$\frac{d\delta b}{dt}=N\delta R_C(t)$

where

$a_1=\frac{\eta (p_s)}{2}{R}_C^{*}+\frac{\eta (p_s)\varsigma (p_s)}{2p_s}{R}_{AI}$

$a_2=\frac{\eta (p_s)}{2}{R}_C^{*},a_3=G_{d}w{R}_C^{*},a_4=p_s{G}_d{(R_C^{*})}^2,g=p_s{R}_C^{*}$

This system of equations can be shown to have the following characteristic function:

$1+G(s)=0$ (23)

(23)

where

$G(s)=e^{-s\tau }\frac{a_3(s+g)(s+\gamma )}{s(s^2+\beta s+\alpha )}$ (24)

(24)

with

$\gamma =\frac{C{p}_s}{w},\beta =g+a_1,\alpha =g(a_1-a_2).$

We now state the stability result for QCN. Let

${\tau }^{*}=\frac{1}{{\omega }^{*}}\left({\tan }^{-1}\frac{{\omega }^{*}}{g}-{\tan }^{-1}\frac{{\omega }^{*}}{\beta }+{\tan }^{-1}\frac{{\omega }^{*}}{\gamma }\right)$ (25)

(25)

where

${\omega }^{*}=\sqrt{\frac{a_3^2}{2}+\sqrt{\frac{a_3^4}{4}+{\gamma }^2{a}_3^2}}$ (26)

(26)

Then ${\tau }^{*}>0$, and the system in equations 21 and 22 is stable for all $\tau \le {\tau }^{*}$.

To prove ${\tau }^{*}>0$, note that because $\beta >g$, it follows that ${\tan }^{-1}\frac{{\omega }^{*}}{g}>{\tan }^{-1}\frac{{\omega }^{*}}{\beta }$.

To apply the Nyquist criterion, we pass to the frequency domain and write equation 24 as

$G(j\omega )=|G(j\omega )|e^{-j\text{arg}(G(j\omega ))}$

where

$\begin{array}{ll}|G(j\omega ){|}^2\hfill & =\frac{a_3^2({\omega }^2+g^2)({\omega }^2+{\gamma }^2)}{{\omega }^2({({\omega }^2-\alpha )}^2+{\beta }^2{\omega }^2)}\hfill \\ \hfill & <\frac{a_3^2({\omega }^2+g^2)({\omega }^2+{\gamma }^2)}{{\omega }^4({\omega }^2+{\beta }^2-2\alpha )}\hfill \\ \hfill & <\frac{a_3^2({\omega }^2+{\gamma }^2)}{{\omega }^4}\hfill \end{array}$

The last inequality follows from the fact that ${\beta }^2-2\alpha >g^2$, which can verified by substituting $\beta =g+a_1,\alpha =g(a_1-a_2)$. Note that setting $\frac{a_3^2({\omega }^2+{\gamma }^2)}{{\omega }^4}=1$, implies that $\omega ={\omega }^{*}$. Hence, it follows that $|G(j{\omega }^{*})|<1$. Because $|G(j\omega )|$ is a monotonically decreasing function of $\omega$, it follows that the critical frequency ${\omega }_c$ at which $|G(j{\omega }_c)|=1$, is such that ${\omega }_c<{\omega }^{*}$. By the Nyquist criterion, if we can show that $\text{arg}(G(j\omega ))<\pi$ for all $0\le \omega <{\omega }^{*}$, then the system is stable. This can be done as follows:

$\begin{array}{ll}\text{arg}(G(j\omega ))\hfill & =\frac{\pi }{2}+\omega \tau +{\tan }^{-1}\left(\frac{\beta \omega }{\alpha -{\omega }^2}\right)-{\tan }^{-1}\frac{\omega }{g}-{\tan }^{-1}\frac{\omega }{\gamma }\hfill \\ \hfill & =\frac{\pi }{2}+\omega \tau +\frac{\pi }{2}-{\tan }^{-1}\left(\frac{\alpha -{\omega }^2}{\beta \omega }\right)-{\tan }^{-1}\frac{\omega }{g}-{\tan }^{-1}\frac{\omega }{\gamma }\hfill \\ \hfill & =\pi +\omega \tau +{\tan }^{-1}\left(\frac{{\omega }^2-\alpha }{\beta \omega }\right)-{\tan }^{-1}\frac{\omega }{g}-{\tan }^{-1}\frac{\omega }{\gamma }\hfill \end{array}$

Because $\alpha >0$, it follows that

$\begin{array}{ll}\text{arg}(G(j\omega ))\hfill & <\pi +\omega \tau +{\tan }^{-1}\frac{\omega }{\beta }-{\tan }^{-1}\frac{\omega }{g}-{\tan }^{-1}\frac{\omega }{\gamma }\hfill \\ \hfill & =\pi +\omega \tau -{\tan }^{-1}\left(\frac{(\beta -g)\omega }{\beta g+{\omega }^2}\right)-{\tan }^{-1}\frac{\omega }{\gamma }\hfill \\ \hfill & \le \pi +\omega \tau -{\tan }^{-1}\left(\frac{(\beta -g)\omega }{\beta g+{({\omega }^{*})}^2}\right)-{\tan }^{-1}\frac{\omega }{\gamma }\hfill \end{array}$ (27)

(27)

The last inequality follows from the fact that $\omega \le {\omega }^{*}$. Defining

$\mathrm{\Psi }(\omega )=\pi +\omega \tau -{\tan }^{-1}\left(\frac{(\beta -g)\omega }{\beta g+{({\omega }^{*})}^2}\right)-{\tan }^{-1}\frac{\omega }{\gamma }$

note that $\mathrm{\Psi }(0)=0$ and for $\tau \le {\tau }^{*}$, $\mathrm{\Psi }({\omega }^{*})\le \pi$. Moreover $\mathrm{\Psi }(\omega )$ is convex for $0\le \omega \le {\omega }^{*}$, which implies that $\mathrm{\Psi }(\omega )\le \pi$ for $\omega \in [0,{\omega }^{*}]$, and from equation 27, it follows that $\text{arg}(G(j\omega ))<\pi$ in this range, so that the Nyquist stability criterion is satisfied.

8.5.1 Discussion of the Stability Result

Writing out the formula for $\left|G(j\omega )\right|$ in detail, we get

${\left|G(j\omega )\right|}^2=\frac{{\left(\frac{G_{d}wC}{N}\right)}^2\left({\omega }^2+{\left(\frac{p_{s}C}{N}\right)}^2\right)\left({\omega }^2+{\left(\frac{p_{s}C}{w}\right)}^2\right)}{{\omega }^2\left({\left({\omega }^2-\frac{g\eta (p_s)\zeta (p_s)R_{AI}}{2p_s}\right)}^2+{\omega }^2{\left(\frac{p_{s}C}{N}+\frac{\eta (p_s)C}{2N}+\frac{\eta (p_s)\zeta (p_s)R_{AI}}{2p_s}\right)}^2\right)}$ (28)

(28)

From equation 28, we can see that the loop gain K for the system is of the order given by

$K~O\left(\frac{C^2}{N}\right)$ (29)

(29)

This is in contrast to TCP Reno (see Chapter 3, Section 3.4), whose loop gain (without RED) is of the order

$K_{RENO}~O\left(\frac{C^3{\tau }^3}{N^2}\right)$

The absence of the round trip latency from the loop gain in equation 29 is attributable to the fact that QCN is not a window-based congestion control algorithm. In both cases, an increase in link capacity C or a decrease in number of connections drives the system toward instability. Because $\tau <<1$, the window based feedback loop plays a role in stabilizing Reno compared with QCN by reducing the system loop gain.

Also note that the critical frequency can be written as

$\begin{array}{ll}{\omega }^{*}\hfill & =a_3\sqrt{\frac{1}{2}+\sqrt{\frac{1}{4}+{\left({\displaystyle \frac{\gamma }{a_3}}\right)}^2}}\hfill \\ \hfill & =\frac{G_{d}wC}{N}\sqrt{0.5+\sqrt{0.25+{\left({\displaystyle \frac{N{p}_s}{G_d{w}^2}}\right)}^2}}\hfill \end{array}$ (30)

(30)

It follows that

$\frac{{\omega }^{*}}{\gamma }=\frac{G_d{w}^2}{N{p}_s}\sqrt{0.5+\sqrt{0.25+{\left(\frac{N{p}_s}{G_d{w}^2}\right)}^2}}$ (31)

(31)

$\frac{{\omega }^{*}}{g}=\frac{G_{d}w}{p_s}\sqrt{0.5+\sqrt{0.25+{\left(\frac{N{p}_s}{G_d{w}^2}\right)}^2}}\mathrm{and}$ (32)

(32)

$\frac{{\omega }^{*}}{\beta }=\frac{G_{d}w}{\left[p_s+\frac{\eta (p_s)}{2}+\frac{\eta (p_s)\varsigma (p_s)N{R}_{AI}}{2C{p}_s}\right]}\sqrt{0.5+\sqrt{0.25+{\left(\frac{N{p}_s}{G_d{w}^2}\right)}^2}}$ (33)

(33)

The last two terms in the denominator of equation 33 are much smaller than the first term. As a result, it follows that $\frac{{\omega }^{*}}{g}\approx \frac{{\omega }^{*}}{\beta }$, so that the stability threshold for latency is given by

${\tau }^{*}\approx \frac{{\tan }^{-1}\lfloor \frac{G_d{w}^2}{N{p}_s}\sqrt{0.5+\sqrt{0.25+{\left(\frac{N{p}_s}{G_d{w}^2}\right)}^2}}\rfloor }{\frac{G_{d}wC}{N}\sqrt{0.5+\sqrt{0.25+{\left(\frac{N{p}_s}{G_d{w}^2}\right)}^2}}}$ (34)

(34)

Substituting G_d=1/128, w=2 and p_s=0.01, we obtain

${\omega }^{*}=\frac{C}{64N}\sqrt{0.5+\sqrt{0.25+0.1024N^2}}$ (35)

(35)

and

${\tau }^{*}\approx \frac{64N}{C\sqrt{0.5+\sqrt{0.25+0.1024N^2}}}{\tan }^{-1}\lfloor \frac{3.125}{N}\sqrt{0.5+\sqrt{0.25+0.1024N^2}}\rfloor$ (36)

(36)

Hence, the stability threshold for the round trip latency is inversely proportional to C and directly proportional to $\sqrt{N}$. For example, substituting C=1 Gbps (=83,333 packets/s) and N=10 yields ${\tau }^{*}\approx 2.158\mathrm{ms}$.

8.6 Further Reading

In addition to QCN, there were two other algorithms that were considered as candidates for the IEEE802.1Qau protocol. The algorithm by Jiang et al. [5] uses an AQM scheme with explicit rate calculation at the network nodes that is fed back to the source. This scheme has some similarities to the RCP algorithm from Chapter 5. The algorithm by Bergamasco and Pan [6] has some similarities to QCN because it is also based on an AQM scheme that provides PI feedback back to the source using a quantized congestion number F_b. The source nodes then use this number to adjust the parameters of their additive increase/multiplicative decrease (AIMD) scheme, such that the rate is additively increased if F_b>0 and multiplicatively decreased if F_b<0.