??? 摘 要：提出了一種基于動態(tài)閾值的AQM策略DS-RED，主要思想是在緩存中設(shè)置一個動態(tài)門限控制包的丟失率，使得緩存可以動態(tài)地分配給各個數(shù)據(jù)流，可以根據(jù)各個數(shù)據(jù)流的不同Qos要求，對其進行有區(qū)別的服務，以更好地滿足網(wǎng)絡Qos要求，從而提高網(wǎng)絡網(wǎng)絡資源的利用率。
??? 關(guān)鍵詞：擁塞控制；主動隊列管理；丟包率；區(qū)分服務
?
??? 目前，互聯(lián)網(wǎng)上已經(jīng)廣泛使用TCP滑動窗口進行端到端的擁塞控制。但是，隨著網(wǎng)絡用戶的增加和所承載業(yè)務流的多元化，端到端擁塞控制正面臨著嚴峻的挑戰(zhàn)。而路由器是互聯(lián)網(wǎng)的核心實體,也是網(wǎng)絡擁塞狀態(tài)最直接的感受者,因而充分發(fā)揮路由器在擁塞控制中的作用也是解決擁塞控制問題的有效思路。而且路由器可能更及時，甚至能夠提前了解網(wǎng)絡的狀態(tài)，并依此實施有效的資源管理策略，保證網(wǎng)絡能有效地避免擁塞或盡早從嚴重的擁塞狀態(tài)中恢復過來。
??? 本文研究的重點是路由器擁塞控制中的隊列管理，隊列管理通過選擇何時丟棄何種業(yè)務流分組來控制隊列長度。
1 主動隊列管理
1.1 Tail Drop
??? 路由器中最常用的隊列管理策略是“尾丟棄”（Tail Drop），從擁塞控制的角度分析，它是一種擁塞恢復機制，也是一種被動隊列管理。但它有3個嚴重缺陷：持續(xù)的滿隊列狀態(tài)；業(yè)務流對緩存的死鎖；業(yè)務流的全局同步。針對這些問題，提出用“首丟棄”和“隨機丟棄”對死鎖和全局同步比較有效，但沒有解決持續(xù)的滿隊列問題。近年來有學者提出主動隊列管理AQM（Active Queue Management）[1-2]讓路由器在擁塞發(fā)生前就采取一些預防措施，使得滿隊列問題比較有效地得到解決。
??? AQM策略試圖通過估算在某點的擁塞并且在緩沖區(qū)滿之前通過丟棄數(shù)據(jù)包來進行標記。相應的擁塞控制策略能夠減小它的傳輸速率。這樣可以避免更加嚴重的擁塞，且試圖降低包的丟失率，保持較低的平均隊列長度。一個AQM算法由兩部分組成：判斷擁塞的發(fā)生和決定該丟棄哪些包。所以它的性能依賴于是積極的還是保守的判斷擁塞的發(fā)生，怎樣根據(jù)判斷結(jié)果主動地丟棄數(shù)據(jù)包。
1.2 RED
??? 去尾算法考慮的是擁塞發(fā)生后如何恢復，如果在擁塞發(fā)生前就采取措施，則可以解決滿隊列問題。AQM正是設(shè)計用來克服網(wǎng)絡中的Tail Drop隊列的缺點。而RED是最早提出的一種AQM算法。
??? RED算法是基于擁塞避免的思路，不是等緩存滿后再丟棄到達的分組，而是利用標記概率事先丟掉部分分組來預防擁塞的發(fā)生。同時，RED 算法不是采用源抑制策略，立刻把反饋信息返回給發(fā)送端，而是通過設(shè)置標志位提示接收端，再由接收端傳遞給發(fā)送端；而且，RED通過平均隊列而非即時隊列來調(diào)整分組的丟失率，以盡可能地吸收部分短暫的突發(fā)流。在隊列頻繁接近于滿緩存時， RED的丟包率明顯小于丟尾隊列。
??? 圖1所示是對兩種算法的仿真曲線圖。由結(jié)果可以得出：隨著流量的增加，兩種算法都產(chǎn)生了不同程度上的延遲，且在高負載的情況下，去尾算法由于全局同步而使隊列震蕩加劇[3-4]。
?
?
2 設(shè)計方案
??? RED算法及很多的改進算法，都不能夠?qū)Σ煌琎os要求的服務提供有區(qū)別的服務，這樣就不能很好地保證高服務質(zhì)量要求的服務。本文中，提出了一種可以實現(xiàn)區(qū)分服務的算法DS-RED（Different Serve RED），在緩存中設(shè)置一個動態(tài)門限來控制包的丟失率，使得緩存可以動態(tài)地分配給各個數(shù)據(jù)流，可以根據(jù)各個數(shù)據(jù)流的不同Qos要求，動態(tài)地調(diào)整網(wǎng)絡資源，從而提高網(wǎng)絡網(wǎng)絡資源的利用率?？梢酝ㄟ^設(shè)置一個門限值，然后根據(jù)高低優(yōu)先級包的丟失情況來動態(tài)調(diào)整這個門限值，使得不同的Qos要求的服務得到有區(qū)別的對待，并且高低優(yōu)先級包丟棄達到一個均衡。使網(wǎng)絡資源得到更加充分的利用。
2.1 算法設(shè)計目標
??? (1)擁塞避免與擁塞控制。實驗表明要維持網(wǎng)絡中的高吞吐量和低延遲，就必須進行擁塞避免；作為擁塞避免失敗的補救措施，必須在路由器上實施擁塞控制，以避免網(wǎng)絡中擁塞崩潰的發(fā)生；
??? (2)實現(xiàn)各數(shù)據(jù)流區(qū)分服務。在緩存中設(shè)置一個動態(tài)門限來控制包的丟失率，使得緩存可以動態(tài)地分配給各個數(shù)據(jù)流，可以根據(jù)各個數(shù)據(jù)流的不同Qos要求，動態(tài)調(diào)整網(wǎng)絡資源，從而提高網(wǎng)絡資源的利用率，它可以通過設(shè)置一個門限值，然后根據(jù)高低優(yōu)先級包的丟失情況來動態(tài)調(diào)整這個門限值，使得不同的Qos要求的服務得到有區(qū)別的對待，并且高低優(yōu)先級包丟棄達到均衡。
2.2 算法思想
??? 為高、低優(yōu)先級數(shù)據(jù)流分別設(shè)置丟失計數(shù)器ch和cl，每個計數(shù)器指定一個丟失增量，例如為kh、kl。當ch每增加kh將會引起門限減少一定值；而cl每增加kl將會引起門限減少一定值。這樣如果太多高優(yōu)先級數(shù)據(jù)包丟失，增大低優(yōu)先級數(shù)據(jù)包丟棄概率的門限值就會減少，以減少低優(yōu)先級數(shù)據(jù)包的緩存空間；反過來，如果太多低優(yōu)先級數(shù)據(jù)包丟失，門限就會增加。使得高低優(yōu)先級包丟棄達到一個均衡。使網(wǎng)絡資源得到更加充分地利用。
3 與RED算法的性能比較
??? 為了比較RED和新算法的性能,進行網(wǎng)絡仿真，仿真使用的網(wǎng)絡拓撲結(jié)構(gòu)如圖2所示。
?
?
??? S1和S2為數(shù)據(jù)發(fā)送源端，其中假定S1發(fā)送高優(yōu)先級數(shù)據(jù)流，S2發(fā)送低優(yōu)先級數(shù)據(jù)流，D1和D2為接收端。瓶頸鏈路位于路由器1和2之間,其鏈路容量為64 kb/s，其余鏈路的容量為10 Mb/s，各主動隊列管理算法設(shè)置在路由器1上。仿真時間為20 s，路由器的緩沖區(qū)大小為50個數(shù)據(jù)包。以上介紹的各種算法的參數(shù)設(shè)置如下：RED基本參數(shù)設(shè)置為min_th=5, max_th=15, max_p=0.02。對于本文提出的方案DS-RED 參數(shù)設(shè)置為 min_th=5, max_th=15, max_p=0.2。下面分別采用恒定速率和文件傳輸FTP的模型對以上的仿真模型進行測試[5-6]，仿真結(jié)果分別如圖3和圖4所示。
?
?
??? 由仿真結(jié)果可以看到，在恒定速率下，兩種算法的丟棄概率是差不多的，但是在FTP文件傳輸?shù)那闆r下，使用改進后的算法高優(yōu)先級數(shù)據(jù)包的丟棄概率明顯降低，而低優(yōu)先級數(shù)據(jù)包丟棄概率相應升高。而改進之前的高優(yōu)先級數(shù)據(jù)包的丟棄概率高于低優(yōu)先級的丟棄概率，改進之后高優(yōu)先級數(shù)據(jù)包的概率明顯低于丟優(yōu)先級的數(shù)據(jù)包的丟棄概率，而且改進后的算法在時間延遲方面也有了明顯改善。
??? 如何減少網(wǎng)絡中的丟包率，提高鏈路的利用率，降低傳輸時延，防止網(wǎng)絡崩潰對網(wǎng)絡研究來說是很重要的。當數(shù)據(jù)包在到達接點前就被丟掉或者是鏈路長時間處于空閑狀態(tài)或者大量不必要的數(shù)據(jù)包重傳都會造成網(wǎng)絡資源的大量浪費。所以網(wǎng)絡的擁塞控制的研究也就變得至關(guān)重要。
??? 通過MATLAB仿真，將該方法與RED算法進行性能比較，結(jié)果表明，改進后的擁塞控制機制能夠提供區(qū)分服務，更好地滿足Qos要求。
參考文獻
[1] FLOYD S, JACOBSON V. Random early detection gateways for congestion avoidance. ACM/IEEETransaction on Networking, 1993. (1): 397-413.
[2] BONALD T, BOLOT J. Analytice valuation of RED performance. Proceeding of IEEE INFOCOM, 2000.
[3] 文遠保, 石正貴. 無線網(wǎng)絡的擁塞控制機制研究[J]. 計算機工程與科學, 2004，26(10).
[4] 任豐原，林闖，劉衛(wèi)東.網(wǎng)絡中的擁塞控制[J].計算機學報，2003，29(9)：1025-1034.
[5] MAY M, LYLES B. Reasonsnot to deploy RED. Seventh International Workshop on Quality of Service, 1999.
[6] 羅萬明.一種支持多媒體通信的擁塞控制機制[J].電子學報，2000，(11)：48-52.