微通信元系統架構下的擁塞控制機制研究

摘要：在簡述現存網絡架構的技術弱點后，提出了微通信元系統架構的思想，微通信元體系結構對不同服務類型的數據構建不同的虛電路進行傳輸。針對這種數據通信策略，提出了一種基于反饋信息位的擁塞控制機制，該機制根據來自路由節點的反饋信息調整一個虛電路發送端的發送速率，以實現擁塞控制。NS仿真表明，此機制能有效提高網絡的吞吐量，改善網絡的性能。

關鍵詞：網絡體系結構； 服務元； 微通信元； 擁塞控制

中圖分類號：TP393文獻標志碼：A

文章編號：1001－3695(2008)03－0844－03

目前互聯網所使用的TCP／IP體系是基于層次體系結構的。隨著全球互聯網的蓬勃發展，人們對網絡的利用和依賴的增加，各種新的網絡服務不斷涌現，從而對網絡的性能[1，2]提出了更高的要求，TCP／IP層次網絡體系所帶來的矛盾也不斷突出。在此基礎上，出現了非層次的計算機網絡體系結構，即服務元的網絡體系結構(service unit based network architecture，SUNA)和與之對應的一個構架，即微通信元系統(micro——communication element system，MCES)[3，4]，旨在通過對體系結構的變更來解決現有層次網絡存在的問題。

任何形式的網絡中擁塞控制均起著非常重要的作用，它直接影響網絡的性能和服務質量（QoS）。由于MCES采用了端到端的虛電路方式傳輸數據（同樣的源、目的節點地址而服務類型不同的數據流將構建不同的虛電路傳送）和滿足某種形式的間隙整形算法[5]，針對這種數據傳輸策略，本文提出了一種基于反饋信息位的擁塞控制機制。

本文介紹了服務元網絡體系結構及微通信元系統架構思想；MCES下擁塞的產生原因及其特殊性，詳細分析MCES中基于反饋信息位的擁塞控制機制，并對它的實現作了詳細說明，并進行仿真與性能分析。

1服務元網絡體系結構和微通信元系統架構

1．1服務元網絡體系結構

服務元網絡體系結構不同于層次體系結構，它認為各個網絡功能部件是一個個的功能元素的集合。服務元網絡體系結構也是模塊化結構，模塊是服務元，服務元是能夠提供服務而又隱藏內部細節的最小實體（硬軟件）。各個服務元之間沒有上下層次關系，由各種不同功能的服務元組合完成各種不同的網絡功能。為了具體說明某服務元為誰提供服務、由什么原因啟動以及如何提供服務，可以把服務元分為五類[3]。

服務元是具有獨立性和擴展性的服務功能模塊，它只提供服務，而不接受服務；它不僅能為本節點應用提供服務，不同節點的服務元還可以合作向某一節點或是整個網絡提供服務。服務元提供服務是通過服務數據單元(service data unit，SDU)完成的。SDU又稱為包（packet）。服務元網絡體系結構的節點模型如圖1所示。

1．2微通信元系統構架

因為服務元是SDU的發送者、接收者、轉發者或變換者（和網絡介質一起組成有源信道）。又因為一個節點包含許多服務元，所以將它們稱為微通信元。相關節點的服務團隊將微通信元組織成微通信系統，再將大量微通信元系統組織成網絡系統。這就是把服務元網絡體系結構的第一個網絡系統稱為微通信元系統MCES構架的原因。

微通信元系統構架的構建原則是容易從TCP/IP過渡而來：包格式盡可能靠近TCP/IP（但要刪除其冗余重復部分），以便簡化包轉換器；大量吸收TCP/IP的成功經驗，如服務功能元素的定義、套接字機制、三次握手建立和釋放連接、TCP的狀態遷徙圖、滑動窗口技術，等等；沿用TCP/IP的系統調用格式，可擴展。

2微通信元系統架構下擁塞的產生原因

微通信元系統架構采用端到端的虛電路方式傳輸數據。虛電路就是指從源節點到目標節點之間由軟件按網絡地址建立起來的通道，如圖2所示。端到端的虛電路意味著對于具有相同的源、目標節點地址而服務類型不同的數據，將構建不同的虛電路來傳送。建立虛電路的包中除了包含節點地址信息外，還應該包含服務類型信息，以便按此服務類型預留資源。而路由器的虛電路表中也應包含服務類型信息，以便按此服務類型使用資源。當路由器收到數據包時，按虛電路表并受預留資源限制（文本數據除外）進行遞交；當收到撤銷虛電路的包時，在虛電路表中刪除相應的項，并釋放資源。三種數據類型的特點和處理方法如表1所示。

微通信元系統架構采用了端到端的虛電路結構以及滿足某種規律的間隙整形算法，保證了所有鏈路都是無擁塞鏈路[5]。因此所有節點都不會被“淹沒”，按道理應該不需要擁塞控制，但嚴格地按預留資源進行發送將導致以下兩種情況的資源浪費：

a）大多數虛電路都存在一個沉默期，即該虛電路一段時間內沒有數據發送，如利用IP電話通話時，說者在說話期間思考問題，這時候，虛電路空閑，而此時其他應用程序卻因為資源不夠而無法正常通信。

b）實時音/視頻通常是要壓縮的，而且壓縮比是變化的。這樣，如果實時音/頻數據流預留的容量按非壓縮值設置為64 kbps，實時視頻MPEG1數據流預留的容量也按非壓縮值設置為1.5 Mbps，實際傳輸時就會存在很多資源的浪費。

為了充分利用這兩種空閑資源，服務元網絡規定文本數據可以利用這些資源，即文本數據流預留的容量按規定值（如平均值的幾分之一）預留資源。實際發送時，為了利用空閑帶寬，一旦網絡有空就發送。這樣的話，就必須要對文本數據的發送進行擁塞控制，否則注入網絡的數據量會超出該主機建立的所有虛電路的帶寬總和。大量主機的這種行為無疑會給網絡造成很大的負擔，直到超出路由器的處理能力，導致很大的轉發延遲甚至丟包，從而引起端主機的重傳，形成惡性循環，導致擁塞的產生。

3微通信元系統架構基于反饋信息位擁塞控制機制

針對微通信元體系結構下數據的傳輸特征（文本數據可以利用音/視頻數據傳輸間隙節省下來的容量）和擁塞的產生原因，提出了一種基于反饋信息位的擁塞控制機制。該機制的基本思想是：來自路由器的反饋信息以一比特位的形式存在于每個分組中（可用當前分組保留位中的一比特位表示），該位的不同取值表示了網絡的擁塞狀況，發送方可以根據此反饋信息來及時評估鏈路的可用帶寬，及時調整擁塞窗口的大小，從而高效地利用帶寬資源，提高文本數據傳輸的吞吐量。因為此比特位獲得了與顯示擁塞通告（ECN）標記相反的結果，筆者稱之為AntiECN標記位。3．1基于反饋信息位的擁塞控制機制的算法實現

在本文的機制中，發送方的每個分組均在頭部攜帶一位AntiECN標記位，此標記位的初始值被置“1”。在虛電路路徑上的每個路由器會判斷自己是否允許該分組所屬的數據流增加它的發送率。如果路由器允許，它就會把存在于分組頭部的AntiECN標記位與“1”進行“與”操作，并且把結果置回分組頭部；如果路由器已經被充分利用，它就會把AntiECN位與“0”進行“與”操作后把結果置回分組頭部。“與”操作確保了分組傳輸的路徑上只要有一個路由器擁塞或者被高效利用，AntiECN標記位都會為0，因此，反饋信息位不會導致已經擁塞的路由器進入擁塞崩潰狀態。最后，接收方通過ACK確認分組回送AntiECN標記位給發送方，發送方根據AntiECN位調整慢啟動和擁塞避免階段的擁塞窗口大小來實現擁塞控制。具體算法如下：

慢啟動階段

a）當AntiECN標記位=1，cwnd（擁塞窗口）

每收到一個ACK確認，cwnd+=MSS(最大分組長度)。在一個RTT時間，擁塞窗口以指數形式成倍增加，直到條件改變。

b）當AntiECN標記位=0，cwnd< ssthresh時，每收到一個ACK確認，cwnd+=(MSS*MSS)/擁塞窗口大小。

擁塞避免階段

c）當AntiECN標記位=1，cwnd≥ssthresh時，

每收到一個ACK確認，cwnd+=int(MSS/K)，K=int(cwnd/(0.5ssthresh))。

d）當AntiECN標記位=0，cwnd≥ssthresh時，

每收到一個ACK確認，cwnd+=(MSS*MSS)/擁塞窗口大小。

3．2基于反饋信息位的擁塞控制機制的分析

對比傳統擁塞控制算法，對本文改進機制具體分析如下：

a）傳統的算法在慢啟動階段總是簡單地以指數形式增加擁塞窗口，這會導致在一個RTT時間擁塞窗口會迅速增加，容易引起丟包現象發生，繼而造成超時重傳。最后，有連接傳輸會以一個非常小的窗口結束在擁塞避免階段，接著在網絡順暢時，再去花費大量時間來增大擁塞窗口的大小，這樣做嚴重影響了連接的吞吐量。而在本文改進的機制中，是根據反饋信息位來調整擁塞窗口的增長速度。算法中(a)情況表明網絡順暢良好，擁塞窗口采取與傳統算法相同的增長策略；(b）情況表明網絡帶寬已經被充分利用，擁塞窗口增長過快可能會導致丟包現象，這時采取傳統的擁塞避免階段的算法，擁塞窗口進入緩慢線性增長狀態。可見，根據AntiECN標記位的不同，在慢啟動階段采用了不同的窗口增長策略對原有算法進行了改進。

b）傳統的算法中，當擁塞窗口的大小達到臨界窗口尺寸（ssthresh）后，就減慢其增長速度，進入擁塞避免階段，即采用算法(b)情況下的緩慢增長策略，而不管此時網絡的實際使用狀況。若此時網絡帶寬資源有剩余，此種機制就限制了文本數據連接傳輸的吞吐量。改進的機制中，在擁塞避免階段，連接也會根據反饋信息位，靈活采用擁塞窗口的增長策略：(a）表明網絡未被充分利用，但擁塞窗口的大小已經達到閾值，因此也不會采用過快的增長策略。機制中，在每個ACK確認按時到達之后，窗口會增長1/K個MSS，在一個RTT時間窗口最多增長1/2個MSS，當擁塞窗口的大小大于1.5倍ssthresh時，每個ACK確認到達后，窗口最多增長1/3個MSS，依此類推。此方法既防止了擁塞避免階段窗口增長過快引起丟包，又防止了窗口增長緩慢而限制了文本數據吞吐量。(b）情況表明網絡已經被充分利用，并且擁塞窗口的大小又達到了閾值，此時采用傳統的擁塞避免算法即可。總之，根據AntiECN標記位的不同取值采用了不同的擁塞避免算法來改進本文數據的吞吐量和網絡性能。

3．3路由器充分利用與否的判定

當一個攜帶反饋信息位——AntiECN標記位的分組到達路由器端時，路由器將根據自己當前的負載情況決定該分組所屬的數據流在下一個RTT時間是否可以增加其發送率。一種簡單的解決方法如下：若當前連接利用率低于一個確定的上限值（稱為閾值，通常是該連接容量的η倍，η<1）或者路由器節點有剩余帶寬（可以由虛電路表中記錄的當前連接預留資源總和計算得到），路由器就認為該連接未被充分利用繼而把AntiECN標記位置1；若當前連接利用率高于一個確定上限值并且路由器節點沒有剩余帶寬，則路由器被充分利用，此時路由器就把AntiECN標記位置0。

為了判斷AntiECN標記位的值，機制中路由器采用類似于顯示擁塞通告標記中使用的自適應虛擬隊列運算法則[6]。路由器提供了一個虛擬隊列，其容量為鏈接容量的η倍，其緩沖區尺寸為B，每一個分組到達時，路由器向虛擬隊列中增加一個假象的分組并進行判定：若隊列是空的，就將AntiECN位置1；隊列非空則置0。如下偽代碼描述了以上的執行情況。

在每個分組到達時：

VQ[aecn]←max(VQ[aecn] η*C(ts)，0)；

/* 更新虛擬隊列大小*/

if VQ[aecn]=0

/*s=前一分組的到達時間*/

將標記位置為1；

/*t=當前時間*/

else

/*b=當前分組的8位組數目*/

將標記位設為0；

/*VQ[aecn]=當前虛擬隊列的8位組數目*/

end if

/*C=路由器的實際接收隊列大小*/

VQ[aecn] ←VQ[aecn]+b；

/*更新虛擬隊列大小*/

機制中路由器端有兩個參數需要設定，確定的上限值η和虛擬隊列的緩沖區大小。虛擬隊列的緩沖區大小將對利用率產生一定的影響，太小的值將使AntiECN位被頻繁地置為1從而導致丟包及網絡性能下降；而太大的值將使鏈接變得保守，文本數據的吞吐量不能得到明顯的提高。

4仿真性能分析

為了驗證本機制的性能，筆者利用NS2工具進行了分析。網絡拓撲圖如圖3所示。這是一個單瓶頸的拓撲結構，其中S為源端；D為接收端；通過帶寬為10 Mbps、延遲為2 ms的鏈路與路由器R相連。n個S到D的連接共享R1到R2的瓶頸鏈路。R1到R2的帶寬為1.5 Mbps；延遲為40 ml。路由器使用FIFO和DropTall隊列管理算法，緩沖區大小設為30個分組，最大數據包長度設為1 600 Byte。為了簡化起見，仿真以FTP作為數據流。

圖3仿真拓撲圖

本文對FTP持續傳送1 Mbps數據、連接數1~30、每個連接在0~5 s之間的隨機啟動進行了仿真。首先，分別對每個連接在η=0.55，η=0.7時和原擁塞控制算法對鏈路的利用率進行了比較。從圖4可以看到，本機制根據AntiECN位來估計鏈路的可用帶寬，避免了慢啟動階段的盲目指數增長，因此能減小分組丟棄數、減小超時重傳分組數，從而提高了鏈路的利用率。另外，擁塞窗口的指數增長時間取決于閾值η，η越大，η的指數增長時間越長。從圖5中還可看出，η取不同值時的連接對鏈路的利用率也不同。因此，設計一個合理有效的η值是筆者將來的主要研究課題。

其次，對一個單連接，采用不同閾值η時的AntiECN擁塞控制機制和原算法（TCP Reno）的吞吐量進行了比較。如圖6所示，η的取值使慢啟動過程指數增長階段的結束時間稍稍提前，這在一定程度上影響了網絡在慢啟動階段的吞吐量。然而， 同TCP Reno相比，本文的機制大大縮短了網絡達到穩定狀態的時間， 并在很大程度上提高了慢啟動階段的吞吐量。并且本文機制在擁塞避免階段也采用了根據反饋信息來調整發送窗口的策略，所以在網絡達到穩定狀態后，網絡的吞吐量還要稍高一些。

圖6吞吐量比較

5結束語

微通信元系統架構是一種新型的網絡體系結構，具有易于從TCP/IP過渡的特點。本文具體分析了該系統架構下擁塞的特殊性，提出了一種基于反饋信息位的擁塞控制機制，并對該機制和傳統機制進行了詳細分析比較。仿真分析看出此機制可以明顯提高了瓶頸鏈路的利用率、改善鏈接的吞吐量，提高了網絡的性能。但該機制需要在路由器端設置兩個參數，即閾值和虛擬隊列緩沖區大小值。這些參數的最優選擇和它們對鏈接的吞吐量及公平性的影響是筆者將來研究的主要內容。

參考文獻：

[1]STEWARE R， SCTP C M．New transport protocol for TCP/IP [J]．IEEE Internet Computing，2001，5(6):64－69．

[2]ENGEL R，KANDLUR D，MEHRA A．Exploring the performance impact of QoS support in TCP/IP protocol stacks[C]//Proc of IEEE INFOCOM’98.1998:883－892．

[3]ZENG Jiazhi，XU Jie，WU Yue，et al．Service unit based network architecture[C]//Proc of Parallel and Distributed Computing，Applications and Technologies Conference. Piscataway: Institute of Electrical and Electronics Computer Society，2003:1216.

[4]曾家智，徐潔，吳躍，等．服務元網絡體系結構和微通信元系統構架[J]．電子學報，2004，32(5)：745－749．

[5]曾家智，趙繼東，易發勝．微通信元系統構架的QoS[J]．計算機科學，2004，31(11)：38－39.

[6]KUNNIYUR S，SRIKANT R．Analysis and design of an adaptive vir￣tual queue algorithm for active queue management[J] ．ACM Compu￣ter Communication Review， 2001，31(4):123134.

[7]BOECKING S，SEIDEL V，VINDEBY P．A runtime system for multimedia protocols[C]//Proc of the 4th International Conference on Computer Communication and Networks.LasVegas:[s.n.]，1995:178－185.

[8]TENNENHOUSE D L， WETHERALL D J．Towards an active network architecture[J].Computer Communication Review，1996，26(2):518.

[9]曾家智，李毅超，韓蒙.計算機網絡[M].成都：電子科技大學出版社，2002:23－96.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”