一個以控制比例速率為基礎的主動佇列管理機制

全文

(1)屏東商業技術學院資訊管理系(所) 碩士學位論文一個以控制比例速率為基礎的主動佇列管理機制. A Proportional Rate-based Control for Active Queue Management. 指導教授：陳俊麟. 研究生：余佳純. 中華民國九十三年六月二十三日.

(2) 摘. 要. 學號：91306006 論文名稱：一個以控制比例速率為基礎的主動佇列管理機制. 總頁. 數：112 學校名稱：國立屏東商業技術學院. 系(所)別：資訊管理系碩士班. 畢業時間及摘要別：九十二學年度第二學期碩士學位論文摘要研究生：余佳純. 指導教授：陳俊麟. 論文摘要內容：本研究主要是在差異式服務(DiffServ)網路上，提出一個新的主動佇列管理(active queue management)機制─以控制比例速率為基礎(A Proportional Rate-based Control)之主動佇列管理機制，來降低在路由器中佇列佔有(queue occupancy)來回激烈震盪的情形。 SRED 與 DRED 是目前唯一能達到佇列穩定的主動佇列管理機制，但仍有些缺點，以至於穩定效果不佳。針對 SRED 及 DRED 的缺點，我們希望設計出一個沒有額外負擔又簡單的封包丟棄機制。因此本研究的目的是設計一個新的並且能夠維持佇列穩定的主動佇列管理演算法。關鍵字：差異式服務、主動佇列管理、以控制比例速率為基礎之主動佇列管理機制。. III.

(3) 誌. 謝. 在這兩年的研究期間，感謝指導教授陳俊麟博士，在學業與生活上悉心指導與教誨，陳老師除了在專業理論方面傾囊相授外，在研究學問的方法以及為人處世方面亦是教導良多，對研究學問的認真態度更是學生學習的典範。於此致上由衷的感謝與敬意。同時，對資管所多位老師與同學之指導與照顧，亦致上衷心的謝意。感謝口試委員李忠憲老師、童曉儒老師與龔旭陽老師，在百忙之中撥冗參加，並不吝提出指導，使本論文更加完善。. IV.

(4) 目. 錄. 碩士論文授權書…………………………………...…………………. Ⅰ. 學位論文審定書…………………………………...…………………. Ⅱ. 摘要………………………………………………...…………………. Ⅲ. 致謝………………………………………………...…………………. Ⅳ. 目錄………………………………………………...…………………. Ⅴ. 圖目錄……………………………………………...…………………. Ⅷ. 表目錄……………………………………………...…………………. ⅩⅣ. 1. 緒論……….……………………………………………………….. 1. 1.1. 研究背景與動機……………………………….……….…..……………. 1. 1.2. 研究目的……………………………………….……………………….... 3. 1.3. 研究步驟……………………………………….……………………….... 4. 1.4. 論文架構………….…………………………….………………………... 4. 2. 文獻探討……………………….………………………………….. 5. 2.1. 差異式服務網路…………………………………………….………….... 5. 2.1.1. 差異式服務網路架構……….…….....………………….……………. 5. 2.1.2. 差異式服務欄位(DSCP)…….......…………...………………………. 8. 2.2. 封包丟棄機制…………………………………….…………………….... 11. 2.2.1. RED………………….………...…...…………….……………………. 12. V.

(5) 2.2.2. FRED…………………......…………...………….……………………. 17. 2.2.3. BRED…………...……………...…………...…………………………. 17. 2.2.4. REM……………...……………………...…………………….………. 18. 2.2.5. BLUE………...………………...………………..………….…………. 19. 2.2.6. SRED…………………...………..………………………….…………. 20. 2.2.7. DRED……………...……………...………..……………….…………. 23. 2.2.8. VRC…..…………………………...……..………………….…………. 25. 2.3. 主動佇列管理技術之比較…………………………...……….…………. 27. 3. 研究方法………………….……………………………………….. 28. 3.1. 封包到達率…………………………………………….……………….... 28. 3.2. SPRC 演算法……...…………………………………….……………….... 33. 3.3. FPRC 演算法…………...……………………………….……………….... 38. 3.4. FPRC with Virtual Queue Update 演算法………………………………... 42. 4. 模擬結果與分析………...……………...…………………………. 45. 4.1. 開發環境與工具…….………………………………………………….... 45. 4.1.1. 系統要求….……...………………………………………………….... 45. 4.2. 實驗 1：二個來源端分別傳送 EF 及 AF1x……………………………..... 46. 4.2.1. 實驗 1：模擬環境….……………….……………………………….... 46. 4.2.2. 實驗 1：比較 DropTail、RED、SRED、DRED 的傳輸量、佇列佔有情形及封包丟棄總量……………....………………………………. 47. 4.2.3. 實驗 1：SPRC 的佇列佔有情形及封包丟棄總量………..……….... 57. 4.2.4. 實驗 1：FPRC 的佇列佔有情形………….……………..………….... 63. 4.2.5. 實驗 1：FPRC 的傳輸量及連線利用率………….…….….……….... 80. VI.

(6) 4.3. 實驗 2：二個來源端皆傳送 AF1x…….………………….……………..... 83. 4.3.1. 實驗 2：模擬環境….…..…………...……………………………….... 83. 4.3.2. 實驗 2：比較 DropTail、RED、SRED、DRED、FPRC、FPRC with Virtual Queue Update 的傳輸量、佇列佔有情形及封包丟棄總量….. 84. 4.4. 實驗 3：十個來源端皆傳送 AF1x……………………………………….. 97. 4.4.1. 實驗 3：模擬環境….…..…………...……………………………….... 97. 4.4.2. 實驗 2：比較 DropTail、RED、SRED、DRED、FPRC 的傳輸量、佇列佔有情形及封包丟棄總量……………………………………..... 98. 第五章結論與建議………..………………...……………………… 110 參考文獻……………………………………...……………………… 111. VII.

(7) 圖目錄. 圖 1-1 研究步驟……………………...………………...…………….…….... 4. 圖 2-1 差異式服務網路架構……..………………………….…………..….. 6. 圖 2-2 差異式服務網路入口路由器之架構………………………...…….... 7. 圖 2-3 差異式服務網路內部路由器之架構……………………………....... 7. 圖 2-4 差異式服務內部路由器之詳細架構……………………...……...…. 8. 圖 2-5 IPv4 的 ToS 欄位或 IPv6 的 Traffic Class…….…………..…….. 10. 圖 2-6 丟棄器方塊圖……………………………………………...……….... 11. 圖 2-7 在RED下，平均佇列長度與丟棄機率的關係………………………. 13. 圖 2-8 RED 機制的各種變化…………………………………………….…. 13. 圖 2-9 WRED-部分重疊………………………………………..………….... 14. 圖2-10 WRED-交錯式…………………………………………………….…. 15. 圖2-11 WRED-完全重疊…………………………………………………….. 16. 圖2-12 在 BRED 下，某一連線的平均佇列長度與丟棄機率的關係………. 18. 圖2-13 常駐表(Zombie list)…………………………………….……………. 21. 圖2-14 SRED 演算法流程圖……………………………………………….... 22. 圖2-15 封閉迴圈的回饋控制系統................................................................... 23. 圖2-16 Proportional rate control 及 VRC 與傳輸量之平衡點………………. 26. 圖 3-1 (a) PktList 之資料結構………………………………………………. 29. 圖 3-1 (b) PktList 紀錄插入及刪除之資料結構……………………………. 29. 圖 3-2 舉例說明封包到達率的計算方式 (a)第 1 個封包到達時 (b)第 4 個封包到達時 (c)第 7 個封包到達時 (d)第 8 個封包到達時…….. VIII. 31.

(8) 圖 3-3 input rate 演算法流程圖……………………………………………... 32. 圖 3-4 input rate 演算法……………………………………………………... 33. 圖 3-5 SPRC 演算法方塊圖……………………………………………….... 34. 圖 3-6 SPRC 演算法流程圖……………………………………………….... 36. 圖 3-7 SPRC 演算法……………………………………………………….... 37. 圖 3-8 FPRC 演算法方塊圖……………………………………………….... 38. 圖 3-9 FPRC 演算法流程圖……………………………………………….... 40. 圖3-10 FPRC 演算法……………………………………………………….... 41. 圖3-11 FPRC with Virtual Queue Update 演算法方塊圖………………….... 42. 圖3-12 FPRC with Virtual Queue Update 演算法流程圖………...…………. 43. 圖3-13 FPRC with Virtual Queue Update 演算法…………………...………. 44. 圖 4-1 實驗 1 之模擬環境…………………………………………………... 47. 圖 4-2 (a) 實驗 1 -傳輸量與時間(sec)之對應圖- DropTail……..…………. 49. 圖 4-2 (b) 實驗 1 -傳輸量與時間(sec)之對應圖- RED…………....………. 49. 圖 4-2 (c) 實驗 1 -傳輸量與時間(sec)之對應圖- SRED………..…………. 50. 圖 4-2 (d) 實驗 1 -傳輸量與時間(sec)之對應圖- DRED…………..…….... 50. 圖 4-3 (a) 實驗 1 -佇列佔有與時間(sec)之對應圖- DropTail…..…………. 52. 圖 4-3 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- RED…………..……... 53. 圖 4-3 (c) 實驗 1 -佇列佔有與時間(sec)之對應圖- SRED………..………. 53. 圖 4-3 (d) 實驗 1 -佇列佔有與時間(sec)之對應圖- DRED………..…….... 54. 圖 4-4 (a) 實驗 1 -封包丟棄總量與時間(sec)之對應圖- DropTail………... 55. 圖 4-4 (b) 實驗 1 -封包丟棄總量與時間(sec)之對應圖- RED……………. 55. 圖 4-4 (c) 實驗 1 -封包丟棄總量與時間(sec)之對應圖- SRED…………... 56. IX.

(9) 圖 4-4 (d) 實驗 1 -封包丟棄總量與時間(sec)之對應圖- DRED………….. 56. 圖 4-5 (a) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.1, αmax = 0.2..... 59. 圖 4-5 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.2, αmax = 0.3…. 59. 圖 4-5 (c) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.6, αmax = 0.7…. 60. 圖 4-5 (d) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.8, αmax = 0.9…. 60. 圖 4-6 (a) 實驗 1-封包丟棄總量與時間(sec)之對應圖- αmin = 0.1, αmax = 0.2……………………………………………………………….... 61. 圖 4-6 (b) 實驗 1-封包丟棄總量與時間(sec)之對應圖- αmin = 0.2, αmax = 0.3……………………………………………………………….... 62. 圖 4-6 (c) 實驗 1-封包丟棄總量與時間(sec)之對應圖- αmin = 0.6, αmax = 0.7……………………………………………………………….... 62. 圖 4-6 (d) 實驗 1-封包丟棄總量與時間(sec)之對應圖- αmin = 0.8, αmax = 0.9……………………………………………………………….... 63. 圖 4-7 (a) 實驗 1 -佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.3….. 65. 圖 4-7 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.5….. 65. 圖 4-7 (c) 實驗 1 -佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.7…... 66. 圖 4-7 (d) 實驗 1 -佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.9….. 66. 圖 4-8 (a) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.1…………….. 67. 圖 4-8 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.2…………….. 68. 圖 4-8 (c) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.3…………….. 68. 圖 4-8 (d) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.4…………….. 69. 圖 4-8 (e) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.5…………….. 69. 圖 4-8 (f) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.6…………….. 70. 圖 4-8 (g) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.7…………….. 70. X.

(10) 圖 4-8 (h) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.8…………….. 71. 圖 4-9 (a) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.3, αmax = 0.6…. 72. 圖 4-9 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.4, αmax = 0.7…. 73. 圖 4-9 (c) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.3, αmax = 0.8…. 73. 圖 4-9 (d) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin =0.3, αmax = 0.9…. 74. 圖4-10 (a) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 3…….... 75. 圖4-10 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 4…….... 75. 圖4-10 (c) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 5…….... 76. 圖4-10 (d) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 6…….... 76. 圖4-10 (e) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 7…….... 77. 圖4-10 (f) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 8………. 77. 圖4-10 (g) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 9…….... 78. 圖4-10 (h) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 10…….. 78. 圖4-10 (i) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 30……... 79. 圖4-10 (j) 實驗 1 -佇列佔有與時間(sec)之對應圖- MaxListQty = 50……... 79. 圖4-11 (a) 實驗 1 -傳輸量與時間(sec)之對應圖- αmin = 0.1, αmax = 0.2……. 82. 圖4-11 (b) 實驗 1 -佇列佔有與時間(sec)之對應圖- αmin = 0.1, αmax = 0.2…. 82. 圖4-11 (c) 實驗 1 -封包丟棄總量與時間(sec)之對應圖- αmin = 0.1, αmax = 0.2……………………………………………………………….... 83. 圖4-12 實驗 2 之模擬環境…………………………………………………... 84. 圖4-13 (a) 實驗 2 -傳輸量與時間(sec)之對應圖- DropTail………………... 86. 圖4-13 (b) 實驗 2-傳輸量與時間(sec)之對應圖- RED…………………….. 87. 圖4-13 (c) 實驗 2 -傳輸量與時間(sec)之對應圖- SRED…………………... 87. XI.

(11) 圖4-13 (d) 實驗 2 -傳輸量與時間(sec)之對應圖- DRED………………….. 88. 圖4-13 (e) 實驗 2 -傳輸量與時間(sec)之對應圖- FPRC………………….... 88. 圖4-13 (f) 實驗 2 -傳輸量與時間(sec)之對應圖- FPRC with Virtual Queue Update………………………………………………….…. 89. 圖4-14 (a) 實驗 2 -佇列佔有與時間(sec)之對應圖- DropTail……………... 91. 圖4-14 (b) 實驗 2 -佇列佔有與時間(sec)之對應圖- RED…………………. 91. 圖4-14 (c) 實驗 2 -佇列佔有與時間(sec)之對應圖- SRED………………... 92. 圖4-14 (d) 實驗 2 -佇列佔有與時間(sec)之對應圖- DRED……………….. 92. 圖4-14 (e) 實驗 2 -佇列佔有與時間(sec)之對應圖- FPRC……………….... 93. 圖4-14 (f) 實驗 2 -佇列佔有與時間(sec)之對應圖- FPRC with Virtual Queue Update………………………………………………….…. 93. 圖4-15 (a) 實驗 2 -封包丟棄總量與時間(sec)之對應圖- DropTail………... 94. 圖4-15 (b) 實驗 2 -封包丟棄總量與時間(sec)之對應圖- RED……………. 95. 圖4-15 (c) 實驗 2 -封包丟棄總量與時間(sec)之對應圖- SRED…………... 95. 圖4-15 (d) 實驗 2 -封包丟棄總量與時間(sec)之對應圖- DRED………….. 96. 圖4-15 (e) 實驗 2 -封包丟棄總量與時間(sec)之對應圖- FPRC………….... 96. 圖4-15 (f) 實驗 2 -封包丟棄總量與時間(sec)之對應圖- FPRC with Virtual Queue Update….……………...……………………….…. 97. 圖4-16 實驗 3 之模擬環境…………………………………………………... 98. 圖4-17 (a) 實驗 3 -傳輸量與時間(sec)之對應圖- DropTail……………….. 100 圖4-17 (b) 實驗 3-傳輸量與時間(sec)之對應圖- RED……………………. 101 圖4-17 (c) 實驗 3 -傳輸量與時間(sec)之對應圖- SRED………………….. 101 圖4-17 (d) 實驗 3 -傳輸量與時間(sec)之對應圖- DRED………………….. XII. 102.

(12) 圖4-17 (e) 實驗 3 -傳輸量與時間(sec)之對應圖- FPRC…………………... 102 圖4-18 (a) 實驗 3 -佇列佔有與時間(sec)之對應圖- DropTail…………….. 104 圖4-18 (b) 實驗 3 -佇列佔有與時間(sec)之對應圖- RED………………… 104 圖4-18 (c) 實驗 3 -佇列佔有與時間(sec)之對應圖- SRED……………….. 105 圖4-18 (d) 實驗 3 -佇列佔有與時間(sec)之對應圖- DRED……………….. 105. 圖4-18 (e) 實驗 3 -佇列佔有與時間(sec)之對應圖- FPRC………………... 106 圖4-19 (a) 實驗 3 -封包丟棄總量與時間(sec)之對應圖- DropTail……….. 107 圖4-19 (b) 實驗 3 -封包丟棄總量與時間(sec)之對應圖- RED…………… 107 圖4-19 (c) 實驗 3 -封包丟棄總量與時間(sec)之對應圖- SRED………….. 108 圖4-19 (d) 實驗 3 -封包丟棄總量與時間(sec)之對應圖- DRED………….. 108. 圖4-19 (e) 實驗 3 -封包丟棄總量與時間(sec)之對應圖- FPRC…………... 109. XIII.

(13) 表目錄. 表 2-1. 差異式服務編碼(DSCP)與逐點傳送行為(PHB)之對照表…………... 表 2-2. DRED 演算法的控制參數....................................................................... 24. 表 2-3. 主動佇列管理技術之比較…………………….…………….…………. 27. 表 4-1. 開發環境與工具…………………………………………………….….. 46. 表 4-2. 實驗 1 -EF 佇列的參數設定- DropTail………………………..….…… 47. 表 4-3. 實驗 1 -AF1x 佇列的參數設定- DropTail、RED、SRED、DRED….. 48. 表 4-4. 實驗 1 -EF 佇列的參數設定- DropTail…………………………….….. 57. 表 4-5. 實驗 1 -AF1x 佇列的參數設定- SPRC…………………………….….. 57. 表 4-6. 實驗 1 -EF 佇列的參數設定- DropTail…………………………….….. 64. 表 4-7. 實驗 1 -AF 佇列的參數設定- FPRC……………………………….….. 64. 表 4-8. 實驗 2- AF 佇列的參數設定- DropTail、RED、SRED、DRED、FPRC、 FPRC with Virtual Queue Update……………………………………..... 表 4-9. 9. 85. 實驗 3- AF 佇列的參數設定- DropTail、RED、SRED、DRED、FPRC.... 99. XIV.

(14) 1. 緒論. 本研究主要是在差異式服務(Differentiated Service, DiffServ) [1] 網路上，提出一個新的主動佇列管理(active queue management)機制─以控制比例速率為基礎(A Proportional Rate-based Control)之主動佇列管理機制，來降低在路由器中佇列佔有(queue occupancy)來回激烈震盪的情形。. 1.1 研究背景與動機. 在過去幾年，有許多的主動佇列管理演算法被提出，如 RED (Random Early Detection) [2]、BLUE [3]、SRED (Stabilized RED) [4]、 DRED (Dynamic RED) [5]等，不過都只針對 TCP/IP 網路來進行設計。由於差異式服務逐漸的盛行，目前也有許多的路由器有支援差異式服務，但目前卻沒有特別針對差異式服務的主動佇列管理演算法，能針對不同的服務型態(service type)，提供特有的佇列管理方式。目前幾個主動佇列管理演算法中，只有 SRED 及 DRED 可以維持佇列穩定，但 SRED 需有額外空間來暫存資料，並且要對每個資料流進行檢查，額外負擔較重。DRED 雖然沒有這些問題，但求得丟棄機率的計算步驟卻十分繁雜。差異式服務是由網際網路工程專案小組(Internet Engineering Task Force, IETF)提出的，透過封包分類的方式，個別針對每個類別(per class) 來提供服務。差異式服務將複雜的分類動作交由邊界路由器(edge router) 來負責，而核心路由器(core router)只需負責快速轉送，因此可以減輕網路中間設備的負擔。. -1-.

(15) 傳統的 IP 網路只提供盡力傳送(best effort)的服務型態，並沒有提供任何能服務品質(Quality of Service, QoS)的保證，針對此點，差異式服務提供二種服務型態：快速傳送(Expedited Forwarding, EF)及確保傳送 (Assured Forwarding, AF)。快速傳送提供低延遲、低遺失、低延遲變動 (jitter)的服務，並擁有專用(premium)的虛擬線路來傳輸服務；而確保傳送則是利用佇列機制進行擁塞控制，以達到差異式服務的功能。一般而言，佇列機制包含二類演算法：佇列排程(queue scheduling) 及佇列管理(queue management)。佇列排程為管理佇列與佇列之間的排程，主要是負責裁決封包傳送的先後次序，並管理每個資料流頻寬的分配，常見的佇列排程有優先權佇列(priority queue)及公平佇列(fair queue) 等；而佇列管理主要是管理封包佇列的長度，通常每個佇列都會有一個丟棄器(dropper)負責控制封包的進入與否，因此又稱為該佇列的政策 (policy)，藉以調整網路流量，避免擁塞，目前最普遍的佇列管理機制為 RED。傳統網路的佇列管理是採用尾端丟棄(DropTail)的方式，此種方式有二種缺點：一是容易造成佇列的溢滿(overflow)，導致優先權較高的封包沒有辦法進入佇列等候服務；另一是可能會發生少數幾個連線獨占佇列的情況，導致其他連線被排擠而無法取得佇列空間，由此可知 DropTail 是無法提供任何的服務品質的。RED 根據平均佇列長度(average queue size)來判斷目前網路擁塞的情形，以決定封包的丟棄機率。RED 通常在佇列未滿之前就會提早且隨機的丟棄封包，因此可以有效避免佇列溢滿的問題。這樣的佇列管理機制又被稱為主動佇列管理(active queue management)機制。不管是哪種主動佇列管理機制，目的都是避免佇列溢滿的現象發生，以期有更多佇列空間來服務較高優先權的封包，提供服務品質保證。. -2-.

(16) 1.2 研究目的. 在過去幾年有許多的主動佇列管理演算法被提出，如 RED、BLUE、 SRED、DRED 等，不過都只針對 TCP/IP 網路來進行設計。由於差異式服務逐漸的盛行，目前也有許多的路由器有支援差異式服務，因此本論文希望就差異式服務來設計一個新的主動佇列管理機制，以期針對不同的服務型態(service type)，提供特有的佇列管理方式。維持佇列的穩定是很重要的，當我們能有效的將封包控制在目標值附近，才能輕易的計算出還有多少可用的佇列空間可供使用。在一些網路設備中，如路由器等，其暫存空間是十分有限的，因此節省下來的佇列空間可以作別的運用，如路由表(routing table)等，這也不失為一個好的應用。 SRED 與 DRED 是目前唯一能達到佇列穩定的封包丟棄機制，但由於 SRED 需要對每個資料流進行監控，並維護一個表格來紀錄這些資料流的資訊，因此容易造成額外的負擔。DRED 雖然不需對每個資料流進行監控，也不需維護額外的表格，但其封包丟棄機率的計算步驟卻十分繁雜。針對 SRED 及 DRED 的缺點，我們希望設計出一個沒有額外負擔又簡單的封包丟棄機制。因此本研究的目的是設計一個新的、簡易的、並且能夠維持佇列穩定的主動佇列管理演算法。. -3-.

(17) 1.3 研究步驟. 本研究之研究步驟如圖 1-1 所示：. DiffServ. Queue management. 相關技術資料蒐集. 相關技術資料蒐集. 資料整理. 問題分析. 根據問題提出解決方法. 進行模擬並比較效能. 結論與建議. 圖 1-1 研究步驟. 1.4 論文架構. 在本論文其餘部分，我們將在第 2 章詳細介紹差異式服務及主動佇列管理機制的技術背景，並彙整與比較。在第 3 章中，則是提出「以控制比例速率為基礎」的主動佇列管理演算法，目的在降低路由器中佇列佔有來回激烈震盪的情形。在第 4 章中，則針對本論文的方法，進行模擬實驗及結果分析。第 5 章則是本論文的結論。. -4-.

(18) 2. 文獻探討. 2.1 差異式服務網路. 整合式服務(Integrated Service, IntServ) [6]與差異式服務同時提供了傳統網路所沒有的服務品質，但差異式服務透過封包分類的方式，針對每個類別(per class)來提供服務，解決了整合式服務中間設備負擔過重的問題，因此較整合式服務更具擴充性(scalability)，更適合應用於高速骨幹網路。. 2.1.1 差異式服務網路架構. 差異式服務網路區域(DiffServ domain)是由邊緣路由器(edge router) 與內部路由器(core router)所組成，邊緣路由器又分為入口路由器(ingress router)與出口路由器(egress router)，如圖 2-1 所示。入口路由器位於差異式服務網路區域的入口處，負責封包的分類及流量控制，並將封包送往內部路由器；內部路由器位於差異式服務網路區域的內部，負責將相同類別的封包聚集(aggregate)在一起並傳送到下一個路由器；出口路由器則位於差異式服務網路區域的出口處，負責將封包送往下一個差異式服務網路區域或其他的網路。. -5-.

(19) DiffServ Domain. Edge router. DiffServ. Edge router. Domain. DiffServ Domain Core router. Core router. Core router. DiffServ. Edge router. Edge router. Domain. DiffServ Domain. 圖 2-1 差異式服務網路架構. 在差異式服務中，由於封包的分類與流量控制等工作都是由入口路由器負責，所以路由器的架構也較複雜，圖 2-2 為入口路由器的架構圖，可分成下列幾個模組： 1、分類器(Classifier)：依據事先協議好的法則，將進入的封包加以分類，由於分類時會參考到封包表頭(header)的多個欄位值的組合，如 source address、destination address、source port、destination port，因此又稱為多欄位(Multi Field, MF)分類器。 2、標記器(Marker)：負責替分類完成的封包標上差異式服務編碼 (Differentiated Service Code Point, DSCP)的標籤。 3、測量器(Meter)：統計進入的封包數量是否符合預先訂定的法則。 4、塑型器(Shaper)：利用緩衝器(buffer)來調節封包數量，以符合協議內容。 5、丟棄器(Dropper)：負責丟棄不符合協議的封包。. -6-.

(20) 圖 2-2 差異式服務網路入口路由器之架構. 由於封包在入口路由器已經過分類，並標上 DSCP，因此內部路由器只需負責檢查進入封包的 ToS (Type of Service)欄位或 Traffic Class 欄位，並將相同 DSCP 的資料聚集在一起送往佇列等候傳送，架構上較入口路由器簡單。圖 2-3 為內部路由器架構圖，可分成下列二個模組： 1、分類器(Classifier)：檢查進入封包表頭的 ToS 或 Traffic Class 欄位，負責將相同 DSCP 的資料聚集在一起，因此又稱為行為聚集(Behavior aggregate, BA)分類器。 2、排隊(Queuing)：包括佇列的排程及佇列的管理。如圖 2-4 所示，各種服務型態，如 EF、AF11、AF21、BE 等，都有自己佇列管理演算法，而佇列間也會根據優先權來進行排程或進行頻寬的分配。. 圖 2-3 差異式服務網路內部路由器之架構. -7-.

(21) 圖 2-4 差異式服務內部路由器之詳細架構 [7]. 2.1.2 差異式服務欄位(DSCP). 由於傳統網路只提供盡力傳送(BE)的服務型態，因此差異式服務提供了另二種的服務型態來達到差異式服務的功能：快速傳送(EF)及確保傳送(AF)，這些服務型態又稱為逐點傳送行為(Per Hop Behavior, PHB)，針對不同的服務型態有不同的服務品質保證，分別用 6 個位元的 DSCP 來表示。表 2-1 為 DSCP 與 PHB 的對應關係。. -8-.

(22) 表 2-1 差異式服務編碼(DSCP)與逐點傳送行為(PHB)之對照表差異式服務編. 逐點傳送行為. 優先等級. 封包丟棄順序. 碼(DSCP). (PHB). (class). (drop precedence). 101110. EF. -. -. 001010. AF11. 001100. AF12. 001110. AF13. 高. 010010. AF21. 低. 010100. AF22. 010110. AF23. 高. 011010. AF31. 低. 011100. AF32. 011110. AF33. 高. 100010. AF41. 低. 100100. AF42. 100110. AF43. 000000. BE. 低 Class 1. Class 2. Class 3. Class 4. 中. 中. 中. 中高. -. -. 下列針對快速傳送(EF)、確保傳送(AF)、盡力傳送(BE)三種服務型態進行解釋： 1、快速傳送(Expedited Forwarding, EF)：提供低延遲、低遺失、低延遲變動的服務品質保證，並擁有專用(premium)的虛擬線路來進行傳輸服務，在傳輸期間可對 AF 及 BE 進行頻寬的剝奪 (preemption)，非常適合用在即時或緊急的資料型態上。 2、確保傳送 (Assured Forwarding, AF) ：將服務依據優先等級 (precedence)分成四種類別(class)，每個類別(class)又分成三個丟 -9-.

(23) 棄順序，通常用 AFxy 來表示，x 代表四種類別，類別高的服務可對類別低的頻寬進行剝奪，例如 AF1y 可剝奪 AF2y、AF3y 或 AF4y 的頻寬；而 y 代表三個丟棄順序，當網路發生擁塞時，高丟棄順序的封包會率先被丟棄，例如 AFx3 會比 AFx2 或 AFx1 先被丟棄。在傳輸期間，除了 AF 彼此之間可進行頻寬的剝奪外，AF 還可對 BE 進行頻寬的剝奪，適用在高傳輸量又非即時性的資料型態上。 3、盡力傳送(best effort, BE)：是三種服務型態中優先等級最低的一種，只能利用 EF 及 AF 分配後剩餘的頻寬來進行服務，傳輸期間頻寬並會遭受 EF 及 AF 的剝奪，所以無法提供任何服務品質的保證，傳統的 TCP/IP 就是屬於此類。. 根據 IETF 的制定，目前主要是利用 IPv4 封包表頭內的 ToS 欄位或 IPv6 封包標頭的 Traffic Class 欄位的前 6 個位元來放置 DSCP 的值，而後 2 個位元為 CU (currently unused)欄位，目前並未使用。其欄位架構如圖 2-5 所示。. 圖 2-5 IPv4 的 ToS 欄位或 IPv6 的 Traffic Class 欄位. 在確保傳送(AF)中，DSCP 的前 3 個位元是用來表示 4 種類別 (class)：001、010、011、100 分別為 AF1、AF2、AF3、AF4 類別；而後 3 個位元是用來表示 3 種丟棄等級：010、100、110 分別為低、中、高的丟棄等級。. - 10 -.

(24) 2.2 封包丟棄機制. 封包丟棄機制主要是用來控管新來的封包是否可進入佇列中等待服務，因此架構上是位於佇列之前，用來判斷新到達的封包應該被丟棄或被接受(accept)而進入佇列。如圖 2-6 所示，每個佇列都有一個封包丟棄機制來控管封包的進入，這些封包丟棄機制又可稱為該佇列的政策 (policy)，藉以調整網路流量，避免擁塞。. 圖 2-6 丟棄器方塊圖. 傳統 TCP/IP 的封包丟棄機制是採用尾端丟棄(DropTail)作為擁塞控制(congestion control)的方法，也就是在佇列未滿之前，所有的封包都可進入到佇列排隊等候傳送，一旦佇列溢滿就從尾端開始將封包丟棄，也就是丟棄所有後續進入此佇列的封包。此種方式有二種缺點：一是容易造成佇列的溢滿(overflow)，導致優先權較高的封包沒有辦法進入佇列等候服務；另一是可能會發生少數幾個連線獨占佇列的情況，導致其他連線被排擠而無法取得佇列空間，由此可知 DropTail 是無法提供任何的服務品質的。解決 DropTail 佇列溢滿的問題，就必須在佇列溢滿之前先行將封包. - 11 -.

(25) 丟棄，並通知傳送端降低封包的傳送速度。這種在佇列未滿前就預先丟棄封包的技術稱為主動的佇列管理(active queue management)。而 RED 是第一個被提出、也是較常被使用的主動佇列管理技術。為了改善 RED 的缺點，目前有許多的主動佇列管理技術被提出，根據其目的可以區分成三類 [8]： 1、以維持每個資料流(per-flow)的公平為目的：如 FRED (Fair RED) [9]、BRED (Balanced RED) [10]。 2、以維持連線的高使用率(high utilization)及封包的低延遲(low delay)為目的：如 REM (Random Exponential Marking) [11]、 BLUE、VRC (Virtual rate control) [12]。 3、以穩定瞬間的佇列長度(instantaneous queue length)為目的：如 SRED (Stabilized RED)、DRED (Dynamic RED)。其運作方式將在下面幾節中提到。. 2.2.1 RED RED 演算法是根據平均佇列長度來判斷目前網路擁塞的狀況，以決定封包丟棄的機率，其特色是在佇列未滿之前就會「提早」且「隨機」的丟棄封包，也因此解決了佇列溢滿的問題。 RED佇列管理演算法是利用下列參數來進行運作： • qavg：平均佇列長度(average queue size)； •. minth：最小門檻值(minimum threshold)；. •. maxth：最大門檻值(maximum threshold)；. •. maxp：最大丟棄機率(maximum drop probability)；. 其運作方式有三種情形，如圖2-7所示： 1、估計佇列的平均大小，即佇列內的封包個數，當平均佇列長度. - 12 -.

(26) 低於最小門檻值，丟棄機率為 0，即允許所有的封包進入佇列。 2、當平均佇列長度介於最小門檻值與最大門檻值間，則依照一定的線性機率來丟棄封包。 3、當平均佇列長度超過最大門檻值，丟棄機率為 1，即所有欲進入佇列的封包皆會被丟棄。. 圖 2-7 在 RED 下，平均佇列長度與丟棄機率的關係. 根據平均佇列長度及門檻值兩參數，RED機制有下列四種變化，通稱為多階層的RED (Multi-level RED, MRED) [13]，如圖2-8所示：. 圖 2-8 RED 機制的各種變化 [13]. 1、單一佇列平均長度單一門檻值(Single Average Single Threshold,. - 13 -.

(27) SAST)：佇列中所有的封包都採用相同的平均佇列長度與相同的門檻值來計算封包丟棄的機率，如 RED。 2、單一佇列平均長度多重門檻值 (Single Average Multiple Threshold, SAMT)：佇列中不管是什麼等級(即不管是經過標記器被標記成紅色、黃色或綠色)的封包皆使用相同的平均佇列長度，而不同等級的佇列使用不同的門檻值，其封包丟棄的機率也不同，如 WRED(Weighted RED)，其門檻值的設定又可分成三種： a、部份重疊(partially overlapped)：各等級的最大及最小門檻值相互重疊，如圖 2-9 所示：. 圖 2-9 WRED-部分重疊 [13]. 其中 • r:minth：標記成紅色封包的最小門檻值； •. y:minth：標記成黃色封包的最小門檻值；. • g:minth：標記成綠色封包的最小門檻值； • r:maxth：標記成紅色封包的最大門檻值；. - 14 -.

(28) •. y:maxth：記成黃色封包的最大門檻值；. • g:maxth：標記成綠色封包的最大門檻值； •. maxpr：標記成紅色封包的最大丟棄機率；. •. maxpy：標記成黃色封包的最大丟棄機率；. •. maxpg：標記成綠色封包的最大丟棄機率；. b、交錯式(staggered)：各等級的最小門檻值剛好為下一等級的最大門檻值，如圖 2-10 所示。. 圖 2-10 WRED-交錯式 [13]. c、完全重疊(overlapped)：各等級的最小與最大門檻值均相同，如圖 2-11 所示。. - 15 -.

(29) 圖 2-11 WRED-完全重疊 [13]. 3、多重佇列平均長度多重門檻值 (Multiple Average Multiple Threshold, MAMT)：佇列中不同等級(即封包經過標記器後被標記成紅色、黃色或綠色)的封包採用不同的平均佇列長度，而不同等級的佇列使用不同的門檻值，如 RIO-C、RIO-DC。 a、 RIO-C(RED. with. In/Out. and. Coupled. virtual. Queues)：需分別計算各種不同等級封包的平均佇列長度，且高丟棄等級的平均佇列長度必需再加上低丟棄等級的平均佇列長度，才可視為高丟棄等級的平均佇列長度。例如紅色佇列的平均佇列長度，需計算出所有紅色、黃色及綠色封包佔據佇列的平均長度。 b、 RIO-DC(RED with In/Out and De-Coupled Queues)：需分別計算各種不同等級封包的平均佇列長度，計算的結果直接為該等級的平均佇列長度，不需再加上低丟棄等級的平均佇列長度。例如紅色佇列的平均佇列長度只需計算紅色封包佔據佇列的平均長度。. - 16 -.

(30) 4、多重佇列平均長度單一門檻值 (Multiple Average Single Threshold, MAST)：佇列中不同等級的封包採用不同的平均佇列長度，而所有不同等級的佇列都使用相同的門檻值來計算封包丟棄的機率，目前此類型並沒有任何的應用。 RED 雖然被廣泛使用，但因為 RED 只依賴平均佇列長度來計算封包丟棄機率，因此有不少的缺點： 1、較其他機制需要大量的佇列空間，才能有較好的表現。 2、參數設定不易，若設定不好其效能會很差。 3、無法精準且快速的反應出目前網路擁塞的情形，容易造成封包丟棄機率被設定的過於激進 (drop-aggressive) 或過於保守 (drop-conservative)。 4、平均佇列長度的計算與目前有多少個連線(active connection)有強烈的關係，導致封包丟棄機率隨著連線數量的增加而增加，隨著連線數量的減少而減少，如此一來容易造成佇列中封包佔有率呈現不穩定(unstable)的震盪。. 2.2.2 FRED FRED(Fair RED)是主動佇列管理技術的一種，其封包丟棄方式與 RED 相似，也是採用二個門檻值及一個平均佇列長度，不同的是 RED 是針對所有進入該佇列的封包，計算整體的平均佇列長度(global average queue length)，而 FRED 則針對每個活動中的連線(active connection)，計算其個別的平均佇列長度。因此 FRED 比 RED 有了更深一層的目的，就是維持每個資料流(per-flow)的公平性，避免佇列被少數幾個資料流獨占。. - 17 -.

(31) 2.2.3 BRED BRED(Balanced RED)作法與 FRED 相似，皆是以維持每個資料流的公平性為目的，因此針對每個活動中的連線(active connection)，計算其個別的平均佇列長度。BRED 與 FRED 最大的不同在門檻值的個數， FRED 是使用二個門檻值(最小門檻值與最大門檻值)，而 BRED 則是使用三個門檻值來決定封包丟棄的機率(令三個門檻值分別為 l1、l2、l3，其中 l1 < l2 < l3)，BRED 並在 l1 至 l2 門檻值間給定一個封包最大丟棄機率(p1)，在 l2 至 l3 門檻值間給定另一個封包最大丟棄機率(p2)，如圖 2-12 所示，其運作情形如下： 1、若平均佇列長度小於 l1，其封包丟棄機率為 0。 2、若平均佇列長度介於 l1 和 l2 之間，其封包丟棄機率最大不超過 p1。 3、若平均佇列長度介於 l2 和 l3 之間，其封包丟棄機率最大不超過 p2。 4、若平均佇列長度大於 l3，其封包丟棄機率為 1。. 圖 2-12 在 BRED 下，某一連線的平均佇列長度與丟棄機率的關係. - 18 -.

(32) 2.2.4 REM REM(Random Exponential Marking)是主動佇列管理技術的一種，以達到佇列高利用率、低封包遺失率及低延遲為目標。REM 演算法以降低擁塞測量與效能測量(如封包遺失、佇列長度、延遲等)之間的耦合程度為宗旨，也就是希望進行擁塞情況的測量時能不受封包遺失、佇列長度等因素影響。演算法主要可以分成二個階段： 1、 match rate clear buffer：主要是利用兩種誤差值的差作為擁塞的量測，一是佇列長度的誤差值(queue mismatch)，即佇列的封包長度與目標值之間的差；另一是速率的誤差值(rate mismatch)，即封包進入佇列的速率與連線可用頻寬(link capacity)之間的差，佇列長度誤差值與速率誤差值之間的差稱為錢值(Price)， REM 利用錢值進行擁塞的量測。當佇列長度誤差值越大(即進入的封包數量超過設定的目標值)，或速率誤差值越大(即封包進入佇列的速率超過連線的容量)，則錢值會越大；反之則越小。 2、 sum prices：REM 利用錢值來計算某一連線封包的標記(或丟棄) 機率，並將某一路徑所經過的所有連線，其封包的標記(或丟棄) 機率加總起來，作為端對端(end-to-end)的封包標記(或丟棄)機率。. 2.2.5 BLUE 在 RED 演算法中，利用了平均佇列長度來計算封包丟棄機率，因為無法精準的反應出目前網路擁塞的情形，因此無法有效的降低封包的遺失率。BLUE 演算法改進了 RED 使用平均佇列長度來計算封包丟棄. - 19 -.

(33) 機率，利用封包遺失(packet loss)的狀況及線路的使用率(link utilization) 來計算封包丟棄機率。在 BLUE 演算法中，每隔一段時間，就需要偵測網路目前的擁塞情行並進行封包丟棄機率的更新，因此演算法可分成下列二種情況： 1、當有封包被丟棄(或佇列溢滿)時，表示目前有大量的封包湧入，目前的封包丟棄機率無法有效的控制擁塞，因此需將封包丟棄機率增加。 2、當線路閒置(link idle)時，表示目前還有大量的佇列空間可提供服務，因此應將封包丟棄機率減少，以允許更多的封包被服務。 BLUE 能精準的反應出目前網路的擁塞情形，因此比 RED 更能有效的降低封包的遺失率及佇列延遲(queuing delay)，加上 BLUE 演算法對佇列空間的要求不高，只需要少量的佇列空間就能有效的進行擁塞控制，因此可以節省更多的路由器空間分配給其他的應用使用，例如節省下的空間可以用來儲存更多的路由表(routing table)。. 2.2.6 SRED RED 演算法的封包丟棄機率會受連線(active connection)數量的多寡影響，因此導致佇列中封包佔有率呈現不穩定(unstable)的震盪；而 BLUE 演算法雖然比 RED 更能有效的進行擁塞控制，卻也無法有效的控制佇列中的封包的數量，因此無法提供保證的佇列空間給下一個資料流使用，這樣的封包丟棄機制並不是非常適合應用在緊急或即時性的資料傳送型態上。 SRED(Stabilized RED)演算法是根據瞬間封包在佇列的佔有率及資料流(active flow)的數量來計算封包丟棄機率，與連線數量無關，因此不會受連線數量的多寡影響，是目前主動佇列管理中少數能達到佇列穩定. - 20 -.

(34) 的方法之一。SRED 利用了一個大小為 M 的表格來紀錄在最近這段時間曾到達佇列的封包資訊，這個表格叫常駐表(Zombie list)，如圖 2-13 所示，紀錄的資訊包括封包的來源端位址、目的端位址、計數(count)、時間戳記(time stamp)等。計數參數是用來紀錄該封包碰撞(hit)的次數。所謂的「碰撞」是指有二個封包的資料流是相同的(即從同一個來源位址送出，且送往同一個目的位址)。時間戳記參數是用來紀錄封包抵達佇列的時間。. 圖 2-13 常駐表(Zombie list). SRED 演算法的運作流程如圖 2-14 所示，可分成下列幾部分： 1、一開始常駐表是空的，當有新的封包到達佇列時，只要常駐表還沒滿，就將新封包的資訊紀錄在常駐表中，並紀錄新封包到達佇列的時間(紀錄在時間戳記中)。 2、當新的封包到達佇列，而常駐表卻已經滿了時，此時隨機的從常駐表中挑選一筆封包資料與新封包進行比對，若是封包資訊比對相同(即 hit)，則將從常駐表中隨機選出的該筆封包資料，其計數值加 1，並將時間戳記更新成新封包到達佇列的時間；反之，若封包資訊比對不同(即 no hit)，則將從常駐表中隨機選出的封包資料更改成新封包的資料，並將計數設定為 0。. - 21 -.

(35) 圖 2-14 SRED 演算法流程圖. SRED 演算法利用計數參數來統計碰撞次數，目的有二個： 1、根據平均碰撞率(average hit rate)，可以估計出資料流(active flow)的數量。 2、根據碰撞的情形可以找出可能是不正常行為(misbehaving)的資料流，這是因為不正常行為的資料流比正常行為的資料流更容易發生碰撞，所謂「不正常行為」是指這類的資料流實際得到的頻寬會多於平均應該分配到的。當封包遺失時，TCP 會啟動重送(retransmission)機制進行封包重送，因此可以根據碰撞的頻率來判斷出何者為不正常的資料流(misbehaving flow)，例如當網路發生擁塞，接收端無法收到封包，而傳送端由於沒有收到回應而一直重送封包，導致佇列中的封包都是由同一個來源送出的，因此碰撞的頻率會很高。. - 22 -.

(36) 基於不正常行為的資料流比正常行為的資料流更容易發生碰撞的理由，SRED 演算法將碰撞因素考慮進去，因此演算法會針對比較激進 (overactive)的資料流增加封包的丟棄機率。. 2.2.7 DRED SRED 與 DRED(Dynamic RED)演算法是目前唯一能達到佇列穩定目標的封包丟棄機制，但因為 SRED 演算法的封包丟棄機率與資料流 (active flow)的數量及封包碰撞的情形有關，因此需要對每個資料流進行監控，並維護一個表格來紀錄這些資料流的資訊，容易造成額外的負擔。 DRED 演算法以比例 - 積分 - 微分 (Proportional-Integral-Derivative, PID)控制器(controller)為基礎，設計了一個封閉迴圈(closed loop)的回饋 (feedback)控制系統，如圖 2-15 所示，表 2-2 為 DRED 演算法的控制參數。系統首先會給定一個目標值(T)，此目標值是我們希望控制的封包數，封包丟棄控制器(packet drop controller)會根據佇列中實際的封包數(q) 與目標值(T)的差距(e)，產生適當的封包丟棄機率(Pd)，以提供程序 (process)丟棄封包，最後，佇列的封包數(q)可能會受到一些其他的因素影響，稱為擾亂因子(d)。. 圖 2-15 封閉迴圈的回饋控制系統 [5]. - 23 -.

(37) 表 2-2 DRED 演算法的控制參數 [14] 參數. 意義. ∆t. 取樣的間隔時間. α. 控制增益(control gain)，與系統的穩定有關. β. 濾波器增益(filter gain). T. 控制目標(control target). B. 佇列長度(buffer size). DRED 演算法之丟棄機率計算流程如下： 1、對目前的佇列進行取樣。 2、計算誤差值，即實際的封包數與目標值的差距。 3、計算訊號經過過濾後的誤差值，這裡是採用低通濾波器 (Low-pass Filter)將較大的訊號過濾掉，目的是避免一些較極端的訊號影響到整體訊號。 4、計算標記或丟棄機率，當誤差值為正數時，表示佇列中的封包數超過目標值，所以應將丟棄機率增加，以減少佇列中的封包；反之，當誤差值為負數時，表示佇列中的封包數低於目標值，此時應該將丟棄機率減少，讓更多的封包可以進入佇列。 5、重複步驟 1-5，以進行下一秒丟棄機率的計算。 DRED 演算法不管是效能或是架構都比 RED、BLUE、SRED 好，其優點有下列幾項： 1、封包丟棄機率的計算與連線(active connection)的個數無關，因此可以達到佇列封包的穩定。 2、佇列中的封包數可以輕易的控制在目標值附近，因此可以輕易的安排剩餘的佇列空間。. - 24 -.

(38) 3、 DRED 不會偏愛 RTT(round-trip time)較短的連線或封包到達速度(arrival rate)較快的連線。 4、架構簡單，利用簡單的回饋系統就可達到不錯的效果。. 2.2.8 VRC VRC (Virtual rate control)也是主動佇列管理演算法之一，他是以速率為基礎的控制機制，因此可以快速的反映出流量的改變，除了維持連線的高利用率及封包的低遺失率外，更可以有效的將佇列長度維持在目標值附近，和SRED及DRED演算法一樣，都可以達到佇列穩定的目標。 VRC演算法藉由控制封包的到達率(input rate)，使封包的到達率能等於輸出端的連線容量(output link capacity)，藉此調整佇列長度及減低封包的延遲(delay jitter)。演算法大致可分成二部分： 1、佇列長度：設立目標佇列長度(target queue length)，利用實際佇列長度與目標佇列長度的差來判斷佇列是否還有足夠的空間能容納新的封包，藉以調整目標封包到達率(target rate)。 2、封包到達率：設立目標封包到達率，利用實際封包到達率與目標封包到達率的差來決定封包的標記/丟棄機率。上述演算法稱為成比例的速率控制(proportional rate control)，但可以發現成比例的速率控制與傳輸量(throughput)之平衡點發生了速率的誤差，如圖2-16所示，利用成比例的速率控制演算法求得的速率( r* )比給定的目標封包到達率( rt* )要來得高，為了矯正此速率誤差，因此作者提出了VRC演算法。VRC演算法與成比例的速率控制演算法原理一樣，但為了矯正速率誤差，因此VRC採用的目標封包到達率( rt* )必須再進行調整，也就是調整成虛擬目標到達率(virtual target rate, rv)，讓VRC與傳輸量的平衡點能正確的落在目標封包到達率( rt* )上。. - 25 -.

(39) 圖 2-16 Proportional rate control 及 VRC 與傳輸量之平衡點 [12]. - 26 -.

(40) 2.3 主動佇列管理技術之比較. 第二章所提到的幾個主動佇列管理技術，其用來測量擁塞的指標都不盡相同，我們將 RED、BLUE、SRED、DRED、REM、VRC 等演算法，及本研究提出的 PRC 演算法的測量擁塞指標作一個整理，並列於表 2-3 中。. 表 2-3 主動佇列管理技術之比較測量擁塞的指標 average queue size. RED. BLUE. REM VRC. PRC. ˇ. instantaneous queue length. ˇ. link utilization. ˇ. number of active flows. SRED DRED. ˇ. ˇ. ˇ. ˇ ˇ. ˇ. ˇ. ˇ. ˇ ˇ. input rate. - 27 -.

(41) 3 研究方法. 本研究目的在提出一個新的主動佇列管理演算法，並期能維持佇列的穩定。本文所提出的方法共有三個，一為以簡單控制比例速率為基礎 (Simple Proportional Rate-based Control, SPRC)之主動佇列管理演算法，一為以完全控制比例速率為基礎(Full Proportional Rate-based Control, FPRC)之主動佇列管理演算法，一為更新虛擬佇列的完全控制比例速率為基礎(FPRC with Virtual Queue Update)之主動佇列管理演算法。 SPRC 演算法主要利用二個控制因子：連線容量(link capacity)及封包到達率(input rate)，來評估目前網路擁塞的情況，以判斷新來的封包應該被丟棄或被接受而進入佇列。FPRC 演算法除了連線容量及封包到達率二個控制因子外，並將佇列長度列入考量，以達到佇列穩定之目標。FPRC with Virtual Queue Update 演算法顧名思義，除了考量連線容量、封包到達率及佇列長度外，每當有封包離開佇列(dequeue)時，會進行虛擬佇列可用容量的更新。. 3.1 封包到達率. 所謂封包到達率(input rate)即每秒有多少個位元(bit)的資料到達。在以控制比例速率為基礎(A Proportional Rate-based Control)之主動佇列管理演算法中，是以每個封包為處理單位，因此只要有封包到達，我們就需要計算出該封包的到達率。為了避免以單個封包來計算速率，可能會造成速率的忽大或忽小，因此我們決定將計算速率的封包個數設成變數，並由使用者給定，以得到一個較平順(smooth)的速率。在進行演算法的說明前，首先針對一些相關參數進行定義： • λ：封包到達率(input rate)，bit/s； - 28 -.

(42) •. PktList：為一個用來紀錄封包資訊的鏈結串列(linked list)，如圖 3-1(a) 所示，其紀錄了封包的到達時間及封包長度。採用鏈結串列的資料結構有助於紀錄的插入及刪除，彈性也較高，如圖 3-1(b) 所示；. •. PktList.qty：為 PktList 內目前紀錄之封包筆數；. • MaxListQty：為 PktList 內所能紀錄之封包最大筆數； • pkt(i)：PktList 內的第 i 筆封包紀錄； • pkt(i).time：PktList 內第 i 筆封包的到達時間(arriving time)， sec； • pkt(i).size：PktList 內第 i 筆封包的長度(packet size)，byte；並假設： • pkt(0)：PktList 內的第一筆封包紀錄； • pkt(n)：PktList 內的最後一筆封包紀錄，當 PktList 為滿的時候，n = MaxListQty； • newPkt：正要被紀錄到 PktList 內的封包紀錄；. 圖 3-1(a) PktList 之資料結構. 圖 3-1(b) PktList 紀錄插入及刪除之資料結構. - 29 -.

(43) 我們用幾個例子來說明封包到達率的計算方式，假設 MaxListQty = 7： 1、當系統剛啟動，第 1 個封包到達時，我們將其到達時間與封包長度紀錄於 PktList 中，如圖 3-2 (a) 所示，我們將剛到達之封包以紅色表示，此時所計算之 λ = (5000 × 8) / (0.1 - 0) = 400000 (bits/s)。 2、只要有新的封包到達，我們就將其到達時間與封包長度紀錄加在 PktList 最後，圖 3-2 (b) 為第 4 個封包到達後的情況，此時所計算之 λ = [(5000 + 12000 + 8000 + 7500) × 8] / (0.41 - 0.1) = 838709.68 (bits/s)。 3、當第 7 個封包來臨，將其紀錄在 PktList 的最後，如圖 3-2 (c) 所示，我們將最早進來的紀錄 1 以灰色表示(表示當有下一個封包來時，該 record 將被移除)，此時所計算之 λ = [(5000 + 12000 + 8000 + 7500 + 8500 + 9000 + 10000) × 8] / (0.67 - 0.1) = 842105.26 (bits/s)。 4、當第 8 個封包來臨，此時 PktList 已滿，如圖 3-2 (d) 所示，我們必須將紀錄 1 移除，並將紀錄 8 加在 PktList 的最後，並設定紀錄 2 為下一個將被移除的紀錄(灰色部分)，此時所計算之 λ = [(12000 + 8000 + 7500 + 8500 + 9000 + 10000 + 15000) × 8] / (0.73 - 0.26) = 1191489.36 (byte/s)。. - 30 -.

(44) (a). (b). (c). (d). 圖 3-2 舉例說明封包到達率的計算方式 (b)第 4 個封包到達時. (a)第 1 個封包到達時. (c)第 7 個封包到達時. (d)第 8 個封包到達時. 經由圖 3-2 的舉例說明後，我們可以知道封包到達率演算法的運作過程。首先設定 MaxListQty，並將剛到達的封包其到達時間及長度紀錄在 PktList 內，當 PktList 內紀錄之封包筆數(PktList.qty)小於 MaxListQty，表示 PktList 未滿，則直接將 PktList 內所有紀錄的封包長度(packet size) 相加，如公式(1)，並計算該封包的到達率(input rate)，如公式(2)所示；反之，當 PktList.qty 大於 MaxListQty，則表示 PktList 內的紀錄已額滿了，則需要將 PktList 內的第 1 筆紀錄移除，並將新紀錄加在 PktList 的最後，再依據公式(1)(2)計算該封包的到達率。. totalSize =. n. ∑ Pkt (i).size. (1). i =0. λ = totalSize / (pkt(n).time - pkt(0).time). - 31 -. (2).

(45) 圖 3-3 為本研究計算封包到達率(input rate)之流程圖：. 圖 3-3 input rate 演算法流程圖. - 32 -.

(46) 圖 3-4 為本研究計算封包到達率(input rate)之演算法：. 圖 3-4 input rate 演算法. 3.2 SPRC 演算法. SPRC 演算法主要是利用二個控制因子：連線容量(link capacity)及封包到達率(input rate)，來評估目前網路擁塞的情況，以判斷該封包應該被丟棄或被接受。圖 3-5 為 SPRC 演算法的方塊圖，每當有封包到達，則擷取該封包的到達時間(arriving time)及封包長度(packet size)進行封包到達率(input rate)的計算(參考 3.1 節)，再比較連線的使用狀況，來判斷目前該封包應該被丟棄或被接受而進入佇列。. - 33 -.

(47) 圖 3-5 SPRC 演算法方塊圖. 在介紹 SPRC 機制前，先針對下列參數進行定義： •. C：連線的容量(link capacity)，bit/s； Cmax：C 的最大門檻值(maximum link capacity)，bit/s； Cmin：C 的最小門檻值(minimum link capacity)，bit/s；. •. α：對某一連線所要求的使用率(desired utilization)，其中 0≦α≦1； αmax：α 的最大門檻值(maximum desired utilization)； αmin：α 的最小門檻值(minimum desired utilization)，其中 αmin≦αmax；. • λ：封包的到達率(input rate)，bit/s； • q：目前佇列內的封包長度，byte；本研究設定 αmax 及 αmin 兩個門檻值的目的，主要是用來限制封包的到達速率，例如某一連線的容量為 100 Mbps，我們設定 αmax 與 αmin 分別為 0.7 及 0.3，也就是說我們限定該連線最大可用的頻寬為 100 Mbps × 0.7 = 70 Mbps，而最低可用的頻寬為 100 Mbps × 0.3 = 30 Mbps。假設此時有一個封包到達，我們首先求得該封包的到達速率，當封包到達速率小於 30 Mbps，可以判定此時 input rate 應小於 output rate，因此我們允許. - 34 -.

(48) 該封包進入佇列；反之，當封包到達速率大於 70 Mbps，此時，該連線的利用率偏高，input rate 有大於 output rate 的可能，因此我們不允許該封包進入佇列，而將之丟棄。因此，利用 αmax 及 αmin 兩個門檻值，可以有效的將封包到達速率控制在我們想要的範圍內。圖 3-6 為 SPRC 演算法的流程圖，其運作如下： • 對某一連線給定一個要求的最大使用率 (maximum desired utilization)及最低使用率(minimum desired utilization)，目的是用來規範該連線的最大可用頻寬及最低可用頻寬。連線最大及最低可用頻寬的公式如公式(3)(4)所示：. Cmax = C × αmax. (3). Cmin = C × αmin. (4). • 每當有封包到達佇列時，計算該封包的到達率。若該封包的到達率小於連線最大可用的頻寬，則允許該封包進入；若該封包的到達率大於連線最大可用的頻寬，則開始進行封包丟棄，直到封包到達率小於連線的最低可用頻寬才停止丟棄封包。. - 35 -.

(49) 圖 3-6 SPRC 演算法流程圖. 圖 3-7 為本研究 SPRC 的演算法。補充一點，在圖 3-7 演算法中的 ” if λ> C ×α ＂，在路由器第一次執行 SPRC 時，α 的初始值為 αmax，之後每當封包到達，則依據 SPRC 演算法來決定 α 為 αmax 或 αmin：. - 36 -.

(50) 圖 3-7 SPRC 演算法. - 37 -.

(51) 3.3 FPRC 演算法. 在 SPRC 演算法中，我們利用了連線容量(link capacity)及封包到達率(input rate)二個因素來評估目前網路擁塞的情況。但我們發現，封包在佇列中的佔有率與佇列長度(queue size)的大小沒有任何關係，也讓佇列失去存在的意義。基於上述理由，我們決定將佇列長度也列入以控制比例速率為基礎(A Proportional Rate-based Control)之主動佇列管理演算法，作為評估網路擁塞的因素之一，我們稱為 FPRC 演算法，圖 3-8 為 FPRC 演算法方塊圖。. 圖 3-8 FPRC 演算法方塊圖. 演算法將在稍後解釋，首先先針對下列變數進行定義： • λ：封包的到達率(input rate)，bit/s； •. Q：實際佇列的大小(actual queue size)，byte；. •. VQ.capacity：虛擬佇列的可用容量(virtual queue capacity)， byte；. •. VQ.threshold：虛擬佇列的門檻值，其中. - 38 -.

(52) 0≦VQ.threshold≦1； • q：目前實際佇列中的封包長度，byte； •. C：連線的容量(link capacity)，bit/s；. •. α：對某一連線所要求的使用率(desired utilization)，其中 0≦α≦1； αmax：α 的最大門檻值(maximum desired utilization)； αmin：α 的最小門檻值(minimum desired utilization)，其中 αmin≦αmax；. •. incoming_packet_size：目前正進入實際佇列的封包長度， byte；. FPRC 演算法是 SPRC 演算法的延伸，除了利用了連線容量及封包到達率作為擁塞控制，也將佇列長度(queue size)列入考量。本演算法利用了虛擬佇列(virtual queue)的觀念，在某個封包到達率的範圍內，有效利用佇列來紓解擁塞情形，讓佇列中封包的佔有情況更有效且更穩定。圖 3-9 為 FPRC 演算法的流程圖，其運作如下： 1、若封包到達率(λ)小於連線最大可用的頻寬(Cmax)，則允許該封包的進入佇列。 2、當封包到達率(λ)大於連線最大可用的頻寬(Cmax)，此時，若虛擬佇列(virtual queue)機制尚未啟動，則進行啟動並計算虛擬佇列的可用容量(VQ.capacity)，虛擬佇列可用容量的計算如公式(5) 所示： VQ.capacity = (Q × VQ.threshold) – q. (5). 每當有封包到達，則將 VQ.capacity 減去該封包長度 (incoming_packet_size)，以計算還有多少可用的虛擬佇列可用容量。當虛擬佇列可用容量小於 0，表示所有虛擬佇列容量已用. - 39 -.

(53) 盡，則將該封包丟棄；否則，表示還有多的虛擬佇列可用容量可存放該封包，則允許該封包的進入佇列。. 圖 3-9 FPRC 演算法流程圖. 圖 3-10 為本研究 FPRC 的演算法，在圖 3-10 演算法中的 ” if λ> C ×α ＂，在路由器第一次執行 FPRC，α 的初始值為 αmax，之後每當封包到達，則依據 FPRC 演算法來決定 α 為 αmax 或 αmin：. - 40 -.

(54) 圖 3-10 FPRC 演算法. - 41 -.

(55) 3.4 FPRC with Virtual Queue Update 演算法. 在 FPRC 演算法中，我們利用了連線容量、封包到達率及佇列長度三個因素來評估目前網路擁塞的情況。但觀察 FPRC 的運作方式，我們發現虛擬佇列在啟動後，並未根據目前封包離開實際佇列(dequeue)所增加的空間，進行虛擬佇列的更新，以致於虛擬佇列未能準確的表現出目前實際佇列所有的可用空間。因此，本節中 FPRC with Virtual Queue Update 演算法，於 dequeue 的程序中，新增了虛擬佇列更新的機制，讓虛擬佇列能根據目前實際佇列的空間，做更準確的控制，圖 3-11 為 FPRC with Virtual Queue Update 演算法方塊圖。. 圖 3-11 FPRC with Virtual Queue Update 演算法方塊圖. 演算法將在稍後解釋，首先先針對下列變數進行定義： •. VQ.capacity：虛擬佇列的可用容量(virtual queue capacity)， byte；. •. dequeued_packet_size：剛離開實際佇列的封包的長度，. - 42 -.

(56) byte； FPRC with Virtual Queue Update 演算法是用來改良 FPRC 演算法其虛擬佇列可用容量未更新的問題。為了讓虛擬佇列能根據目前實際佇列的空間，做更準確的控制，本演算法每當有封包離開實際佇列時 (dequeue)，且虛擬佇列已被啟動時，就會將該封包的空間加回虛擬佇列的可用容量，以進行虛擬佇列可用容量的更新。圖 3-12 為 FPRC with Virtual Queue Update 演算法的流程圖，圖 3-13 為 FPRC with Virtual Queue Update 的演算法：. 圖 3-12 FPRC with Virtual Queue Update 演算法流程圖. - 43 -.

(57) 圖 3-13 FPRC with Virtual Queue Update 演算法. - 44 -.

(58) 4 模擬結果與分析. 本章中，我們針對差異式服務網路，設計 3 個實驗劇本(scenario)來進行模擬，除了比較 J-Sim 模擬軟體已存在的佇列管理機制外： DropTail、RED、SRED、DRED，也模擬了本文所提供的方法：SPRC、 FPRC 及 FPRC with Virtual Queue Update 演算法，並進行結果分析，以證明以控制比例速率為基礎(Proportional Rate-based Control)之主動佇列管理演算法的效能較其他的機制好。. 4.1 開發環境與工具. 本實驗是採用 J-Sim [7]模擬軟體來進行模擬。J-Sim 是一套以元件為基礎(component based)的軟體架構，在 J-Sim 中，一個網路、一個路由器、一個連線(link)等、甚至是一個協定(protocol)，都視為是一個元件，這樣的軟體架構稱之為自治元件架構 (autonomous component architecture, ACA)。 J-Sim 是採用雙語言(dual-language)的方式來撰寫程式：Java 及 Tcl， Java 語言主要是用來撰寫 J-Sim 模擬軟體的系統類別(class)；Tcl 語言則是像黏著劑(glue)一樣，負責建立、設定及控制網路模擬。除了上述標準的 Tcl 指令外，J-Sim 又額外提供了二種延伸的 Tcl 指令：Tcl/Java command 及 RUV (runtime virtual) system command，其中 Tcl/Java 指令是負責在 Tcl 環境下建立及存取 Java 物件(object)。. 4.1.1 系統要求. 本研究的開發環境所採用的作業系統為 Windows XP，網路模擬軟. - 45 -.