歸因擁塞貢獻的制作方法
【專利摘要】一種歸因針對相應(yīng)用戶寄存器的共享資源的擁塞貢獻的方法，所述資源可操作以對服務(wù)的請求提供服務(wù)，多個所述請求中的每一個都具有與其相關(guān)聯(lián)的、指示所述請求與多個用戶寄存器中的哪一個寄存器相關(guān)聯(lián)的用戶指示。
【專利說明】歸因擁塞貢獻
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及用于歸因針對相應(yīng)用戶寄存器的共享資源的擁塞貢獻的方法和裝置。
[0002]更具體地說，本發(fā)明的多個方面涉及用于歸因針對相應(yīng)用戶寄存器的共享資源(如數(shù)據(jù)網(wǎng)絡(luò)或其中的轉(zhuǎn)發(fā)節(jié)點)的擁塞貢獻的方法和裝置，該資源可操作以服務(wù)針對諸如請求轉(zhuǎn)發(fā)的數(shù)據(jù)單元的服務(wù)的請求，該請求具有與其相關(guān)聯(lián)的、指示與多個用戶寄存器中的哪一個寄存器相關(guān)聯(lián)的用戶指示。該用戶寄存器可以與網(wǎng)絡(luò)的用戶(如數(shù)據(jù)的發(fā)送方或接收方)相關(guān)聯(lián)，并且與對與用戶寄存器相關(guān)聯(lián)的請求提供服務(wù)有關(guān)地和/或與向與用戶寄存器相關(guān)聯(lián)的用戶提供的服務(wù)有關(guān)地，根據(jù)這樣確定的擁塞貢獻來進行服務(wù)確定和起作用。
【背景技術(shù)】
[0003]首先，作為背景信息介紹某些基本概念，以易于理解此后介紹的許多監(jiān)測和監(jiān)管技術(shù)。
[0004]包
[0005]數(shù)據(jù)發(fā)送方通常將要發(fā)送的數(shù)據(jù)分成已知為包的較小單位。每一個包都由報頭和運送要遞送的數(shù)據(jù)的凈荷構(gòu)成。該報頭包含根據(jù)相關(guān)通信協(xié)議限定的域?，F(xiàn)今，由商業(yè)網(wǎng)絡(luò)運送的絕大部分包是所謂的IP包。IP是網(wǎng)際協(xié)議。這確保路由器網(wǎng)絡(luò)可以將任何包從源轉(zhuǎn)發(fā)至其目的地。IP是無連接協(xié)議，其意指每一個數(shù)據(jù)包中的報頭信息針對路由器充分自包含，以獨立于其它包來遞送報頭信息；每一個包甚至可以采用不同的路由器到達目的地。
[0006]分布式帶寬共享和擁寒
[0007]穿過因特網(wǎng)的數(shù)據(jù)跟隨由不同路由協(xié)議控制的一系列路由器之間的路徑。每一個路由器都尋求將包移動得更接近其最終目的地。如果太多通信量穿過網(wǎng)絡(luò)中的同一路由器，則該路由器可能變得擁塞并且包在利用該網(wǎng)絡(luò)路徑的同時開始經(jīng)歷過度延遲。在路由器之間，數(shù)據(jù)還穿過也可能變得擁塞的開關(guān)和其它連網(wǎng)設(shè)備。在下面的描述中，術(shù)語路由器擁塞將被用于表示任何網(wǎng)絡(luò)設(shè)備的擁塞。在沒有普遍性損耗的情況下，如果源堅持通過該路由器發(fā)送通信量，則其可以可能變得嚴重過載(擁塞)甚至丟棄通信量(當其緩沖器溢出時)。如果源仍堅持通過該瓶頸發(fā)送通信量，則其可能迫使更多的路由器變得擁塞，而如果該現(xiàn)象保持蔓延，則其可以導(dǎo)致針對整個因特網(wǎng)的擁塞崩潰，其在二十世紀八十年代中期有經(jīng)常發(fā)生。
[0008]已經(jīng)有了針對該問題的解決方案，以通過實現(xiàn)擁塞控制機制，來確保源針對它們通過因特網(wǎng)發(fā)送數(shù)據(jù)的速率來承擔責任。源監(jiān)測來自接收方的具有特征化路徑擁塞的指標的反饋，以便檢測它們的數(shù)據(jù)正跟隨的路徑變得擁塞的時刻，在該情況下，它們通過縮減它們的吞吐量做出反應(yīng)，同時它們可以在不存在路徑變得擁塞的跡象時緩慢增加它們的速率。
[0009]源監(jiān)測的典型路徑特征化指標是針對數(shù)據(jù)路徑的平均往返時間(RTT)、往返時間的變化(不穩(wěn)定性)以及該路徑上的擁塞水平。擁塞是控制通過擁塞路徑發(fā)送數(shù)據(jù)的源的速率自適應(yīng)的參數(shù)之一。
[0010]擁塞水平可以隱含地(通過丟棄包的擁塞路由器)或者明確地(通過諸如明確擁塞通知的機制-參見下一分段)信令通知。當前，最常見的選項是隱含信令。
[0011 ] 利用TCP的源能夠檢測損失，因為包損失導(dǎo)致序列中的間隙；無論何時TCP源檢測到損失，其都意味著減半其數(shù)據(jù)發(fā)送速率，但每往返時間不多于一次，其減輕了該瓶頸處路由器上的擁塞。
[0012]隨機早期檢測(RED)
[0013]歷史上，路由器在它們變得完全飽和時將丟棄包(其在通信量突發(fā)無法容納在路由器的緩沖器中時發(fā)生)，該策略被稱作尾部丟棄(drop-tail)。隨機早期檢測(RED)(在參考文獻“ [RED] ”中討論的，稍后給出其書目細節(jié))是一種改進方案，由此路由器監(jiān)測它們的緩沖器中的平均隊列長度，并且在該平均隊列高于指定閾值時，路由器以隨著該隊列超過該閾值的多余長度而增加的概率開始丟棄包(參見圖3)。RED現(xiàn)今在因特網(wǎng)中廣泛使用，因為其避免了同一時間(稱作同步)接收擁塞信號的全部流，其否則將造成振蕩。RED還允許源振蕩初期擁塞更迅速起反應(yīng)，并且其抑制隊列生長得不必要地長。
[0014]顯式擁塞通知
[0015]顯式擁塞通知(ECN)(參見參考文獻“ [RFC3168] ”)還利用IP報頭中的兩比特ECN域信令擁塞來改進RED。其運行和RED相同的算法，但并不丟棄包，其將其ECN域設(shè)置成擁塞經(jīng)歷(CE)碼點。ECN標準需要接收器將數(shù)據(jù)中信令的任何擁塞標記發(fā)出回聲；例如，TCP接收器在TCP報頭中設(shè)置回聲擁塞經(jīng)歷(ECE)標志，TCP源解釋其好像包已經(jīng)出于其速率控制的目的而被丟棄。依次地，源接著通過減半其發(fā)送速率來對擁塞做出反應(yīng)。
[0016]ECN 針對 DECnet 初始限定，由 Digital Equipment Corporation[DECbit]開發(fā)的專有聯(lián)網(wǎng)協(xié)議。像在IP中采用的構(gòu)思一樣，其也在幀中繼和ATM中采用，但在這后兩者協(xié)議中，網(wǎng)絡(luò)內(nèi)部地排列擁塞信號的反饋，并且網(wǎng)絡(luò)強制通信量限制，以防止擁塞形成(參見[ITU-T Rec.1.371])。
[0017]IEEE標準化了顯式擁塞方法，其中，以太網(wǎng)不切換被設(shè)置成反饋擁塞信號的終端系統(tǒng)，盡管希望發(fā)送系統(tǒng)上的以太網(wǎng)裝置通過響應(yīng)于信號縮減其速率來協(xié)作。該方法排它地專用于針對諸如數(shù)據(jù)中心的同質(zhì)環(huán)境。
[0018]在先前描述的方法中，每一個幀(或包)正好攜帶一個二進制標志并且擁塞信號的強度取決于標記幀的比例，有效地，采用流O和I的擁塞信號的一元編碼。然而，IEEE方案在每一個反饋幀中信令多比特擁塞水平，因此，其常見名稱:量化擁塞通知或QCN(參見[IEEE802.1Qau])。
[0019]Re-ECN
[0020]Re-ECN(參見[re-ECN])利用稱作再反饋的技術(shù)(在[re-feedback]和國際申請W02005/096566中討論的)，由此，包指示它們很可能在它們的路徑的其余部分上經(jīng)歷的擁塞，而不只是ECN指示的、已經(jīng)經(jīng)歷的擁塞。其類似于ECN，而在包報頭中使用額外未使用比特。該比特與該兩比特ECN域相組合，以創(chuàng)建四個額外碼點，如在國際申請W02006/079845中討論的。
[0021]用于理解該協(xié)議的最簡單方式是將每一個包想象為具有不同“顏色”的標志(其中，不同“顏色”對應(yīng)于不同碼點)。在流的起點，將“綠色”標志(“FNE”，意指“未建立反饋”)用于指示發(fā)送方?jīng)]有足夠的路徑知識。綠色標志還在發(fā)送方不肯定有關(guān)路徑的當前狀態(tài)時使用。
[0022]默認的是，包用“灰色”標志標記。如果它們在它們通過網(wǎng)絡(luò)的進展期間遭遇擁塞，則通過擁塞路由器應(yīng)用的ECN標記將被稱作“紅色”標志。目的地將反饋對其已經(jīng)看到的紅色標志的計數(shù)。對于通知的每一個紅色標志來說，發(fā)送方應(yīng)當利用“黑色”標志標記其在隨后包或多個包中發(fā)送的等同字節(jié)數(shù)。該黑色標志再發(fā)回聲或?qū)砣答佋俨迦牖氐桨那跋蛐羞M流中，因此，叫做“re-ECN”。這些黑色標志一旦它們已經(jīng)被發(fā)送方發(fā)送就不能被修改。存在黑色包將又被擁塞路由器標記紅色的較小可能性，但選擇碼點以使其仍可能斷定該包初始標記為黑色，這種包括被描述為帶彩色“黑-紅”。
[0023]在任何中間節(jié)點處，上游擁塞根據(jù)紅色標志字節(jié)與總字節(jié)的比例給出。因而，通過將紅色或非紅色標記流分別解釋為一元編碼的I或0，而在包流中有效編碼連續(xù)變化的擁塞水平。類似的是，整個路徑擁塞水平被編碼為黑色或非黑色標記流。因而，來自任何中間節(jié)點的預(yù)期下游擁塞可以根據(jù)黑色標志的比例與紅色標志的比例之差來估計，如在國際申請TO2006/079845中描述的。
[0024]IETF在基于re-ECN限定針對網(wǎng)際協(xié)議(IP)的實驗性變化的處理中，稱作擁塞暴露(ConEx)(參見[ConEx-abstr-mech])。
[0025]現(xiàn)有摶術(shù)討論
[0026]針對每一個數(shù)據(jù)源擁塞的分布式擁塞控制響應(yīng)不必公平地或有效地共享帶寬。首先，該方法針對存在的擁塞依靠在規(guī)定方法中自發(fā)響應(yīng)的源。其次，即使所有源如規(guī)定地響應(yīng)，每一個數(shù)據(jù)流的源也不考慮其怎樣相對于其它源隨著時間活動或不活動。第三，應(yīng)當在具有真實世界身份的實體(例如，網(wǎng)絡(luò)的用戶或客戶)而非抽象數(shù)據(jù)流之間判定公平。要不然，某些真實世界實體就可以簡單地創(chuàng)建比其它更加多的數(shù)據(jù)流。
[0027]由此，網(wǎng)絡(luò)存在于通常限制共享網(wǎng)絡(luò)的使用。這一般被稱作“監(jiān)管”。
[0028]通信鏈路的物理容量提供了針對該鏈路的用戶可以獲得的比特率的自然物理限制。為將客戶站點(例如，家庭或商業(yè))接合至網(wǎng)絡(luò)而提供的鏈接物理地限制客戶的通信量。
[0029]然而，通常來說，在去往或來自客戶站點的比特率上放置邏輯而非物理限制。這是因為，隨著接入鏈路的峰值帶寬伴隨技術(shù)提升而增加，平均接入鏈接利用率也隨著增加(目前，在典型峰值時段期間，1%的平均利用率)。因此，當來自具有低平均利用率的大量客戶的通信量更深入地聚集到網(wǎng)絡(luò)中時，不經(jīng)濟的是，針對每一個用戶可能短暫地使用它們100%的接入容量的偶然性來提供共享容量。
[0030]典型地講，來自大集合客戶的平均通信量可公平預(yù)測。對于網(wǎng)絡(luò)運營商來說，可以針對這種平均提供足夠的容量，加上足夠的凈空以考慮每日變動。然而，在高峰時間，接著，根據(jù)負擔最重的用戶(有多少和它們負擔有多重)來確定每個人的經(jīng)歷。
[0031]體
[0032]已經(jīng)設(shè)計了許多方式來邏輯上監(jiān)管共享容量的使用。一些在生成網(wǎng)絡(luò)中使用，其它僅作為研究建議:
[0033]今牌捅監(jiān)管:參照圖la，并且入在[Turner86]中進一步討論的，網(wǎng)絡(luò)運營商向每一個客戶i分配一定約速率Ui和一定約突發(fā)尺寸Iv令牌桶監(jiān)管器與每一個客戶相關(guān)聯(lián)，其本質(zhì)上是存儲特征化客戶近期活動的單一數(shù)字Cli的賬戶。概念地，屯是客戶令牌桶的填充時變深度，其按恒定速率Ui填充令牌并且可以存在多達匕個令牌。計量器測量客戶通信量并且針對傳遞的每一個字節(jié)從桶中去除令牌。因此，按時變比特率Xi發(fā)送的客戶將按速率Xi從桶中去除令牌。
[0034]監(jiān)管器根據(jù)桶的填充深度Cli來調(diào)節(jié)客戶可以發(fā)送通信量的速率yi。只要桶不是空的(CliX))，監(jiān)管器就不阻止客戶的數(shù)據(jù)流Xi。但無論何時桶中存在不足的令牌Wi = O)，都丟棄抵達數(shù)據(jù)。如果客戶未充分利用該契約，則桶將變滿并且將丟棄填充桶的另一些令牌。
[0035]可能的變形:例如，
[0036]-在桶的底部透支，其中，丟棄的概率隨著透支的深度增加；
[0037]-延遲而非丟棄(稱作，修整而非監(jiān)管)
[0038]-標記為契約外，而非丟棄(下面參見R10)。
[0039]配對令牌桶:可以向客戶提供它們總是能夠使用特定比特率(它們的承諾信息速率或CIR)的擔保，但如果共享容量可用，則它們也被允許使用直至峰值信息速率(PIR)。這兩個速率還與超過該速率的允許突發(fā)尺寸相關(guān)聯(lián):分別為，承諾突發(fā)尺寸(CBS)和峰值突發(fā)尺寸(PBS)。CIR/PIR契約通常根據(jù)按兩個速率分別填充并且分別具有兩個突發(fā)尺寸深度的配對令牌桶來監(jiān)管。該布置典型地稱作三色標記(TCM)，因為它們通常根據(jù)兩個、一個桶是否為空或者是否都不為空來標記(或“著色”)具有三個不同服務(wù)類別之一的傳出通信量[RFC2697, RFC2698]。
[0040]CIR/PIR方法在幀中繼和ATM中常見，并且其現(xiàn)今常用于共享鏈路上，其中，接入容量技術(shù)包括用于均分容量的機制(例如，有線網(wǎng)絡(luò)或無源光學(xué)網(wǎng)絡(luò)中的時分復(fù)用或蜂窩網(wǎng)絡(luò)中的碼分復(fù)用)。提供鏈路容量，以使其可以支持所有承諾信息速率的和。該方法還被用于整個網(wǎng)絡(luò)，而非僅用于鏈路，例如，差異化服務(wù)(DiffServ)網(wǎng)絡(luò)[RFC2698]。對于一網(wǎng)絡(luò)來說，承諾速率可能不受保證，-可以提供共享容量，以使其具有滿足全部承諾速率的高概率。
[0041]另一變形只擔保一次承諾速率而非兩次，而且一次關(guān)聯(lián)承諾突發(fā)尺寸，但如果準許可用容量，則還允許峰值突發(fā)尺寸[RFC2697]。
[0042]具有(RIO)的RED:R10(還在[Clark98]中進一步討論)將有關(guān)哪一個通信量在契約之外的判定與有關(guān)是否契約通信量之外的批準的判定分開。其按兩種變形出現(xiàn)，每一個在概念上都是另一個對偶:
[0043]-基于發(fā)送方的監(jiān)管:在網(wǎng)絡(luò)的入口處，任何上述監(jiān)管器設(shè)計都可以被用于確定哪一個通信量在契約中而哪一個在契約外。但契約外通信量僅同樣加標志，而非丟棄。事實上，客戶可以標志它們自己的通信量，以指示哪一個契約外包對于它們來說不太重要；接著，網(wǎng)絡(luò)運營商僅必須檢查標志為契約內(nèi)的通信量，實際上不在定約通信簡檔內(nèi)配合。
[0044]如果在更深入到網(wǎng)絡(luò)中的任何正向節(jié)點處存在擁塞，則標志為契約外的包可以在丟棄契約內(nèi)包之前被優(yōu)先丟棄。RIO方案提出，更深入到網(wǎng)絡(luò)中的節(jié)點可以簡單地運行RED算法的兩個實例，一個具有用于契約外通信的聚合閾值，而另一個具有正規(guī)閾值配置。
[0045]-基于接收方的監(jiān)管:在該變形中，如果通信量穿過擁塞隊列，則其在概率上標記有標準顯式擁塞通知(ECN)。因而，正好在抵達接收器之前，利用上述監(jiān)管技術(shù)之前來比較通信量與定約簡檔。但代替丟棄包或在契約外標志它們地，針對簡檔內(nèi)的所有通信量去除ECN標記。
[0046]加權(quán)RED(WRED):WRED(在[WRED_Cisco]中進一步討論)是已經(jīng)廣泛實現(xiàn)的RIO的基于發(fā)送方版本的變形。像RIO—樣，在網(wǎng)絡(luò)入口處，針對與客戶一致的契約，監(jiān)管通信量。而且像RIO—樣，監(jiān)管器標志而非丟棄簡檔之外的通信量。但不是將通信量標志為契約內(nèi)或者契約外，WRED監(jiān)管器而是潛在地利用八個通信類別標識符來降級契約外通信量。對于UE差異化服務(wù)來說，典型地使用三個類別，如針對DifTServ的有擔保轉(zhuǎn)發(fā)類別標準化的[RFC2597])。
[0047]在內(nèi)部路由器上，針對每一個類別配置多達八組不同RED閾值，并且一個算法(而非RIO中的兩個)確定平均隊列長度。接著，比較每一個包與和其類別有關(guān)的閾值，以使被降級至更低領(lǐng)先類別的包將更可能被丟棄。
[0048]題名為“Congestion avoidance profiles in a packet switching system” 的美國專利US6，904，015 (Chen等人)涉及用于按硬件實現(xiàn)加權(quán)RED算法的技術(shù)。在Chen的技術(shù)中，通信量調(diào)節(jié)器存儲丟棄概率簡檔，作為可配置簡檔片段的集合。多級比較器比較針對包隊列的平均隊列尺寸(AQS)與該片段，并且確定AQS位于哪一個片段內(nèi)。該片段針對對應(yīng)丟棄片段鍵入，其被用于標記針對包的包丟棄/容許判定。在一優(yōu)選實現(xiàn)中，該計算核心被一組寄存器包圍，其目的是，允許其服務(wù)多包隊列和具有不同丟棄優(yōu)先級的包。
[0049]瓶頸流監(jiān)管:一種有時被稱為受罰席監(jiān)管的技術(shù)[Floyd99]涉及監(jiān)測來自FIFO隊列的丟棄，以標識來自特定流的包與其它相比在該丟棄中是否更普遍。隨后公布了針對該原始構(gòu)思的許多變形和改進，如伴隨優(yōu)選丟棄的RED(RED-PD[Mahajan01])、最少近期使用RED (LRU-RED [ReddyOl])、XCHOKe [Chhabra02]，以及近似公平丟棄(AFD [Pan03])。
[0050]這些瓶頸流監(jiān)管機制的意圖是，利用比其它流更高的比特率來標識應(yīng)用數(shù)據(jù)流，以便監(jiān)管它們的下降至和每一個其它流一樣的速率。
[0051]帶內(nèi)擁寒令牌桶監(jiān)管:參照圖lb，這在操作上類似于令牌桶監(jiān)管，但只有在其對擁塞有貢獻時才考慮其通信量。先決條件是，在別處對擁塞有貢獻的通信量比例必須被標志到通信量本身上，如帶內(nèi)擁塞信令。這還在[Jacquet08]和國際申請W02006/082443中進行了討論，
[0052]典型地講，每一個包都利用與其已經(jīng)貢獻的擁塞成比例的概率來標記或者不標記。這可以利用顯式擁塞通知(ECN[RFC3168])或擁塞暴露(ConEx[ConEx-abstr-mech])來實現(xiàn)。計量器僅測量擁塞標記包而互連其余的。其僅針對標記包的字節(jié)從擁塞令牌桶中去除令牌。網(wǎng)絡(luò)運營商向每一個客戶i分配一約定擁塞比特率Zi和一定約擁塞突發(fā)尺寸Cio概念上，這些用填充速率和深度表示為具有傳統(tǒng)令牌桶。此外，當客戶的擁塞令牌桶是空的是，監(jiān)管器限制它們的比特率。
[0053]可能的變形:
[0054]-可以使用雙令牌桶，其中，像限定的令牌填充速率一樣，將令牌排放率限制成最大。國際申請W02010/109201公開于此。
[0055]-代替二進制擁塞標記地，每一個包都可以用0&1之間的實數(shù)標記，表示其已經(jīng)經(jīng)歷的擁塞水平。例如，量化擁塞通知(QCN)中的反饋幀[IEEE802.1Qau]按這種方式標志。接著，計量器計數(shù)要從桶中去除的擁塞字節(jié)，作為數(shù)據(jù)幀中的字節(jié)數(shù)乘以與該幀相關(guān)聯(lián)的數(shù)字式擁塞水平。
[0056]加權(quán)公平排隊(WFQ):參照圖lc，WFQ利用鏈路活動地分區(qū)實體之間的容量，而不會浪費不活動實體上的容量。實體可以被限定為正規(guī)客戶或個體數(shù)據(jù)流。每一個實體都與一權(quán)重相關(guān)聯(lián)，以使可以提供故意不等的共享。來自每一個活動實體的通信量被分區(qū)成分離隊列。針對共享線路的接入通過排程器來調(diào)停，該排程器針對特定時間比例服務(wù)每一個隊列，Wi/Sw,其中,Wi是與實體i相關(guān)聯(lián)的權(quán)重,而Sw是全部活動實體的權(quán)重之和。這向每一個客戶賦予鏈路容量Y的擔保最小比例，等于Wi Υ/ΣW。如果客戶發(fā)送比這更多，則它們的隊列正好堵塞(buildup)。如果它們發(fā)送的更少，則它們的隊列排放，而且無論何時它們的隊列為空，即使在包之間的短暫時段，排程器也將向其它客戶賦予更高比例的鏈路，因為將不包括不活動用戶的權(quán)重，同時它們沒有在隊列中等待的包。這在[WFQ89][WFQ_Cisco]中進一步討論。
[0057]深包檢杳(DPI):DPI機使用網(wǎng)絡(luò)處理器來重建應(yīng)用層包流，并且標識哪些包屬于哪些應(yīng)用。因而，對于網(wǎng)絡(luò)運營商來說，可以配置區(qū)別其推斷很可能占用大量容量的特定應(yīng)用的策略，但可能不被大部分客戶特別高度重視。
[0058]DPI機還被設(shè)置成，能夠識別來自每一個個體客戶的通信量并且計數(shù)總?cè)萘?，或針對每一個客戶賬戶的特定應(yīng)用的容量。常見應(yīng)用是，組合DPI機的能力，以使僅限制在那一天高峰時段期間貢獻了總通信量的較大比例部分的那些用戶的對等式文件共享通信量。
[0059]沒有標準的DPI機，該方法完全專用的。但總體上，可以把包分類階段看作類似于迄今描述的所有方案的階段，其檢查低到通信量是否適合簡檔、是否允許將通信量分類為契約內(nèi)或者契約外。另選的是，至于WRED，可以限定進出之間的頻譜。
[0060]已經(jīng)分類良好通信量怎樣遵循通信量契約，因而，DPI區(qū)使用已經(jīng)描述的計數(shù)的全部范圍來劣化契約外通信量，在需要時，針對網(wǎng)絡(luò)中其它地方的潛在處理從丟棄至標識來變動。
[0061]另外，DPI區(qū)可以不同地路由特定分類的通信量，以改進或劣化其服務(wù)。
[0062]Comcast協(xié)議-不可知擁塞管理系統(tǒng):Comcast與Sandvine —道開發(fā)的系統(tǒng)(參見[Fairshare])采取以下步驟:
[0063]-其在幾分鐘時段期間測量來自每一個客戶的通信量(上游)的容量并且記錄最近每客戶指標。
[0064]-該網(wǎng)絡(luò)監(jiān)測特定區(qū)段是否變得擁塞。
[0065]-如果是，則該系統(tǒng)標識已經(jīng)在最近的過去貢獻大部分通信量的該區(qū)段的那些用戶，并且將他們?nèi)康耐ㄐ帕恐概涓蛢?yōu)先級類別達短暫時段。
[0066]-無論何時該區(qū)段變得擁塞，那些用戶的通信量都因而比別處每一個人都接收更低優(yōu)先級服務(wù)，并由此可以延遲或丟棄。
[0067]-一旦那些客戶縮減它們的貢獻低于閾值，它們就不再被指配更低優(yōu)先級。
[0068]參考文獻
[0069][RED]: S.Floyd&V.JacobsonRandom Early Detection gateways for CongestionAvoidance” , IEEE/ACM Transactions on Networking, Voll-4 (397-413) Augl993.[0070][RFC3168]:Ramakrishnan, K.K., Floyd, S.&Black, D.: "The Addition of ExplicitCongestion Notification (ECN) to IP", Internet Engineering Task Force Request forcomments3168 (September2001).[0071][Chhabra02] Parminder Chhabraj Shobhit Chuigj Anurag Goel，AjitaJohn, Abhishek Kumar, Huzur Saranj and Rajeev Shorey.XCHOKe:Malicious sourcecontrol for congestion avoidance at Internet gateways.1n Proc.1EEE InternationalConference on Network Protocols (ICNP^ 02).1EEE (November2002)
[0072][DECbit] Jain, R.，Ramakrishnanj K.&Chiu，D.，"Congestion Avoidance inComputer Networks With a Connectionless Network Layer, "Digital EquipmentCorporation Technical report DEC-TR-506 (1987)
[0073][Floyd99]Floyd, S.&Fall，K.，"Promoting the Use of End-to-End CongestionControl in the Internet, 〃IEEE/ACM Transactions on Networking? (4):458—472 (August1999)
[0074][ITU-T Rec.1.371] !^Traffic Control and Congestion Control inB-1SDNj "ITU-T Recommendation 1.371 (03/04) (March 2004) <http://www.1tu.1nt/rec/recommendation, asp ? type = folders □ = e&parent = T-REC-1.371>
[0075][MahajanOl]Ratul Mahajanj Sally Floyd, and David Wetheral.Controllinghigh-bandwidth flows at the congested router.1n Proc.1EEE International Conferenceon Network Protocols (ICNP^ 01) (2001) [0076][Pan03] Rong Pan, Lee Breslau, Balaj i Prabhakerj and Scott Shenker.Approximate fairness through differential dropping.ACM SIGC0MM ComputerCommunication Review, 33 (2): 23 - 40 (April2003)
[0077][ReddyOl] Smitha A.L.Narasimha Reddy.^LRU-REDiAn active queuemanagement scheme to contain high bandwidth flows at congested routers, "In ProcGlobecomm’ 01(November2001)
[0078][re-feedback]: Briscoe, B.，Jacquetj A.，Cairano-Gilfedderj C.D.，Salvatori,A.，Sopperaj A.&Koyabe, M.:"Policing Congestion Response in an Internetwork UsingRe-Feedback"，Proc.ACM SIGCOMMi05，Computer Communication Review35(4):277-288ACMPress (Aug2005).[0079][re-ECN]: B.Briscoe, A.Jacquet，T.Moncaster，A.Smith: "Re-ECN: AddingAccountability for Causing Congestion to TCP/IP〃，IETF Internet Draft draft-briscoe-tsvwg-re-ecn-tcp-09 (0ct2010).[0080][ConEx-abstr-mech]:Mathis, M.&Briscoe，B.，"Congestion Exposure (ConEx)Concepts and Abstract Mechanism, "Internet Engineering Task Force Internet Draft draft-mathis-conex-abstract-mech-00(0ctober2010)(Work in progress)
[0081][IEEE802.1Qau]:"IEEE Standard for Local and Metropolitan Area
Networks---Virtual Bridged Local Area Networks-Amendment:10: Congestion
Notification, 〃IEEE Draft standard802.1Qau Draft2.4(2006) Abstract URL:http://www.1eee802.0rg/l/pages/802.lau.html
[0082][Turner86]: Turner，J.，〃New Directions in Communications，〃IEEECommunications Magazine24 (10): 8—15 (0ctoberl986)[0083][RFC2697]: Heinanen，J.&Guerin，R.，"A Single Rate Three Co lorMarker, "Internet Engineering Task Force Request for comments2697 (Septemberl999)
[0084][RFC2698]:Heinanen, J.&Guerin, R.，"A Two Rate Three Color Marker, "InternetEngineering Task Force Request for comments2698 (Septemberl999)
[0085][Jacquet08]:Jacquet，A., Briscoe, B.&Moncaster,T.，"Policing Freedomto Use the Internet Resource Pool,^In:Proc Workshop on Re-Architecting theInternet (ReArchi08)ACM (December2008)〈http://www.bobbri scoe.net/pubs.html#polfree>
[0086][WFQ89]:Demers, A.，Keshavj S.&Shenker, S.，"Analysis and Simulation of aFair-Queueing Algorithms, "Computer Communication Review (SIGCOMMi 89) 19 (4):1—12 (Septemberl989)
[0087][WFQ—Cisco]: "Distributed Weighted Fair Queuing, "Cisco Feature Guide Webpage http://www.cisco, com/en/US/does/ios/1l_l/feature/guide/DWFQ.html(1992)
[0088][Clark98]: Clark, D.D.&Fang，W.，"Explicit allocation of best-effortpacket delivery service, 〃IEEE/ACM Transactions on Networking6(4):362—373IEEEPress (Augustl998):D01:http://dx.do1.0rg/10.1109/90.720870
[0089][WRED—Cisco]:"Weighted Random Early Detection on the Ciscol2000SeriesRouter, "Cisco Systems Feature Guide IOS Software Releasell.2 (I)GS (April2005)
[0090][RFC2597]: Heinanen, J.，Baker, F.，Weiss, W.&Wroclawski, J.，"Assured Forwarding PHB Group,"Internet Engineering Task Force Request forcomments2597 (Junel999)
[0091][Fairshare]:Bastianj C.，Klieberj T.，Livingoodj J.，Mills, J.&Woundy, R.，"Comcast’s Protocol-Agnostic Congestion Management System,"Internet EngineeringTask Force Request for Comments6057 (December2010)
[0092][uTPIO]: Norberg，A.，〃uTorrent transport protocol, ^BitTorrent.0rgBitTorrent Enhancement Proposals (BEPs) 0029 (January 2010) (Draft)http://www.bittorrent.0rg/beps/bep—0029.html
[0093]現(xiàn)有公開與本發(fā)明的相關(guān)性
[0094]根據(jù)這些現(xiàn)有公開，被認為與本發(fā)明最相關(guān)的那些是:
[0095]-帶內(nèi)擁塞令牌桶(IBCTB)監(jiān)管(圖1b)
[0096]-深包檢查
[0097]-Comcast協(xié)議-不可知擁塞管理系統(tǒng)
[0098]-瓶頸流監(jiān)管器
[0099]前三個都能夠?qū)⑾拗凭劢褂谠诟叻迨褂脮r段期間貢獻更多容量的那些客戶。帶內(nèi)擁塞令牌桶(IBCTB)監(jiān)管被認為與本發(fā)明最相關(guān)，因為其僅精確地標識直接在隊列中貢獻擁塞的容量。 [0100]另兩個(DPI和Comcast解決方案)僅廣泛地標識在擁塞通常較高時段期間貢獻大部分容量的那些。但高容量的源實際上可能與特定隊列中擁塞的擁塞時段不相符。
[0101]這樣的問題在于，因為最近已經(jīng)部署新的“后臺”擁塞控制協(xié)議[UTP10]，其將按擁塞的最初跡象快速縮減速率，讓步其它“前臺”通信量。因而，前臺通信量可以短暫按高速率傳遞，由此，更早完成，以使后臺傳遞可以恢復(fù)，并且仍幾乎沒有任何延遲地完成。遺憾的是，像DPI和Comcast解決方案的方法不能檢測針對擁塞的這種快速響應(yīng)，因而，它們不實地指責在擁塞期間貢獻高容量的業(yè)務(wù)，而事實上那時，正好完全相反。假定大約20%的因特網(wǎng)通信量使用uTP (在其與2010年初被引入時)，這是一種關(guān)鍵性的忽略。
[0102]與此相反，ECN在擁塞實際上發(fā)生時，在非常短暫的幾微秒期間標記呈現(xiàn)在隊列中的通信量的容量。因此，即使傳遞其非常高的容量，帶內(nèi)擁塞令牌桶(IBCTB)監(jiān)管也能正確地允許通過高度響應(yīng)于擁塞的通信量。同時其正確地限制在擁塞期間貢獻大量容量的通信量，而非如此快速響應(yīng)。
[0103]帶內(nèi)擁塞令牌桶(IBCTB)監(jiān)管在某些方面可以被看作一種理想的解決方案，因為其精確地標識客戶貢獻擁塞的通信量，由此，精確地測量有多少客戶約束其它客戶的經(jīng)歷，或則等同地，有多少客戶需要增加網(wǎng)絡(luò)容量。在經(jīng)濟方面，其測量通信量的精確邊際成本。
[0104]然而，帶內(nèi)擁塞令牌桶監(jiān)管固有地需要將包帶內(nèi)地標志有擁塞信息。因此，至少擁塞暴露(ConEx)必需加以部署，而且理想的是，也部署顯式擁塞通知(ECN)。這兩種部署可能未出現(xiàn)有一些年了并且可能未廣泛分布。它們需要針對涉及終端系統(tǒng)和網(wǎng)絡(luò)兩者的部署的協(xié)調(diào)步驟。
[0105]本發(fā)明的優(yōu)選實施方式旨在提供這樣一種機制，即，其允許將客戶所貢獻擁塞的簡檔與針對該客戶的允許簡檔相比較，其中，所貢獻擁塞從擁塞站點傳送至通信量“帶外”監(jiān)管器。
[0106]瓶頸流監(jiān)管器使用與本發(fā)明實施方式表面上類似的機制。然而，它們的目標是，盡可能快速地標識應(yīng)用數(shù)據(jù)流，其在使用比其它流更高的比特率。完全與此相反，本發(fā)明優(yōu)選實施方式的目的是，允許不同客戶短期內(nèi)按完全不同速率運行，但無論何時擁塞變高都標識哪些客戶持久性地貢獻更多容量。事實上，即使一客戶從未有比其他人更快發(fā)送的瞬間(她可能由于過度持續(xù)而完全沖突)，本發(fā)明的特定實施方式也可以很好地挑選出該客戶。
[0107]不同于瓶頸監(jiān)管器，本發(fā)明實施方式涉及累計客戶對擁塞的貢獻，而沒有隨著時間的任何衰減。與此相反，瓶頸監(jiān)管器快速衰減或暫停擁塞貢獻，以便僅基于最近擁塞貢獻來計算速率的近瞬間測量。代替隨著時間衰減擁塞貢獻，本發(fā)明實施方式對所累計擁塞貢獻與也累計(但按恒定速率)的允許簡檔進行比較。
[0108]因為其更長的時間范圍，所以本發(fā)明優(yōu)選實施方式固有地涉及與客戶相關(guān)聯(lián)的全部通信量，而非個體應(yīng)用數(shù)據(jù)流。當擁塞可能改變時并且當用戶可能展示不同水平的活動時，它們隨著時間來累計擁塞貢獻。結(jié)果，當擁塞停止累計時，它們可以謹慎地將來自客戶(流之間)的缺乏通信量處理為暫緩。與此相反，瓶頸監(jiān)管器僅在個體應(yīng)用數(shù)據(jù)流運行時涉及它們的近瞬時速率。如果大量客戶都同時變得活動達一時段，則只要它們在該時段都造成大約等量的擁塞，瓶頸監(jiān)管器就不計數(shù)針對任何流的高度擁塞。

【發(fā)明內(nèi)容】

[0109]根據(jù)本發(fā)明第一方面，提供了一種歸因針對相應(yīng)用戶寄存器的共享資源的擁塞貢獻的方法，所述資源可操作以服務(wù)針對服務(wù)的請求，多個所述請求中的每一個都具有與其相關(guān)聯(lián)的、指示所述請求與多個用戶寄存器中的哪一個寄存器相關(guān)聯(lián)的用戶指示；所述方法包括以下步驟:
[0110]根據(jù)每一個相應(yīng)用戶寄存器的預(yù)定特征重復(fù)地更新該每一個相應(yīng)用戶寄存器；
[0111]根據(jù)從共享所述資源的用戶接收的請求更新多用戶擁塞測量；
[0112]并且針對接收的請求:
[0113]-根據(jù)與請求相關(guān)聯(lián)的用戶指示來標識與所述請求相關(guān)聯(lián)的用戶寄存器；
[0114]-根據(jù)更新后的所述多用戶擁塞測量來更新關(guān)聯(lián)的所述用戶寄存器的狀態(tài)；以及
[0115]-根據(jù)關(guān)聯(lián)的所述用戶寄存器的更新后的狀態(tài)來確定可歸因于關(guān)聯(lián)的所述用戶寄存器的共享資源的擁塞貢獻。
[0116]根據(jù)優(yōu)選實施方式，所述資源可操作以對數(shù)據(jù)網(wǎng)絡(luò)內(nèi)的服務(wù)的請求提供服務(wù)。其例如可以是數(shù)據(jù)網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)節(jié)點(或者在其中/通過其設(shè)置)。
[0117]根據(jù)優(yōu)選實施方式，請求可以是諸如包的數(shù)據(jù)單元，在該情況下，該資源可以是可操作以服務(wù)針對諸如數(shù)據(jù)單元的服務(wù)的請求的網(wǎng)絡(luò)節(jié)點，其請求經(jīng)由一個或更多個數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)。關(guān)于數(shù)據(jù)單元的所述用戶例如可以是所述數(shù)據(jù)單元的發(fā)送方；所述數(shù)據(jù)單元的一個或更多個希望接收方；或者對于發(fā)送和/或接收所述數(shù)據(jù)單元有責任的實體的指示。
[0118]根據(jù)優(yōu)選實施方式，更新的所述多用戶擁塞測量與所述接收的請求分開傳送，由此允許更新關(guān)聯(lián)的所述用戶寄存器的狀態(tài)。例如，在所述接收請求數(shù)諸如包的數(shù)據(jù)單元的情況下，所述更新多用戶擁塞測量可以利用分離消息，而非利用數(shù)據(jù)單元本身來傳送。作為替代或補充，針對已經(jīng)被拒絕的服務(wù)的請求被重新用作用于傳送更新后的所述多用戶擁塞測量的手段，由此，允許更新關(guān)聯(lián)的所述用戶寄存器的狀態(tài)。
[0119]根據(jù)優(yōu)選實施方式，關(guān)聯(lián)的所述用戶寄存器的狀態(tài)按取決于為服務(wù)的所述請求提供服務(wù)所需的所述資源的量的測量的量和取決于所述多用戶擁塞測量的量來更新。
[0120]根據(jù)優(yōu)選實施方式，更新所述多用戶擁塞測量的步驟包括以下步驟:根據(jù)所述資源是否對服務(wù)的所述請求提供服務(wù)，來更新所述多用戶擁塞測量。
[0121]根據(jù)優(yōu)選實施方式，所述多用戶擁塞測量依靠根據(jù)接收到的所述服務(wù)的請求所更新的多用戶寄存器本身的狀態(tài)來更新，由此模擬所述接收到的請求應(yīng)當怎樣由與所述共享資源相比能力較差的資源提供服務(wù)。在這種實施方式中，所述多用戶寄存器可以被看作“虛擬隊列”。
[0122]根據(jù)優(yōu)選實施方式，所述用戶寄存器可以根據(jù)它們各自預(yù)定特征而周期性地更新。作為替代或補充，在接收到具有指示與該用戶寄存器關(guān)聯(lián)性的用戶指示的請求的情況下，根據(jù)該用戶寄存器的預(yù)定特征進行更新。
[0123]根據(jù)優(yōu)選實施方式，所述用戶寄存器可以包括實現(xiàn)令牌桶或漏桶功能的模塊。
[0124]根據(jù)優(yōu)選實施方式，所述方法還可以包括以下步驟:與對與用戶寄存器相關(guān)聯(lián)的請求提供服務(wù)有關(guān)地和/或與向與用戶寄存器相關(guān)聯(lián)的用戶提供的服務(wù)有關(guān)地，根據(jù)這樣確定的擁塞貢獻來進行服務(wù)確定。接著，所述方法還可以包括以下步驟:根據(jù)所述服務(wù)確定為服務(wù)的請求提供服務(wù)，或者發(fā)送所述服務(wù)確定的指示，由此使得能夠根據(jù)所述服務(wù)確定來為服務(wù)的請求提供服務(wù)。
[0125]根據(jù)本發(fā)明第二方面，提供了 一種用于執(zhí)行根據(jù)第一方面所述方法的裝置。
[0126]上面引用的和下面描述中的不同選項和優(yōu)選實施方式可與第一和第二方法有關(guān)地應(yīng)用。[0127]本發(fā)明優(yōu)選實施方式可以被看作提供了一種折衷方法，S卩，其可以不向網(wǎng)絡(luò)中的單一區(qū)賦予基于“帶內(nèi)”擁塞信號(如ConEx和/或ECN)的擁塞監(jiān)管的全部權(quán)益，但它們可以單向地部署。
[0128]它們具有針對上述和圖1b所示IBCTB監(jiān)管的相似性，但根據(jù)優(yōu)選實施方式，通常應(yīng)當部署在網(wǎng)絡(luò)中的最可能擁塞的位置處，在那里，它們通過關(guān)聯(lián)來自本地隊列的每一個丟棄與傳遞該包的客戶，而非計數(shù)包上的帶內(nèi)顯式擁塞標記并關(guān)聯(lián)它們與客戶，來本地計量擁塞。接著，正如帶內(nèi)擁塞令牌桶監(jiān)管器，它們根據(jù)該本地計數(shù)擁塞來排放每一個客戶的擁塞令牌桶。
[0129]圖2例示一優(yōu)選實施方式，其使用將被稱作“帶外擁塞令牌桶”(00BCTB)監(jiān)管的技術(shù)?？梢钥闯?，一個大容積先入先出(FIFO)緩沖器與全部客戶的令牌桶監(jiān)管器相關(guān)聯(lián)。該緩沖器被示出保持不同尺寸的包隊列。這是可以變得擁塞的數(shù)據(jù)轉(zhuǎn)發(fā)裝置，其通常需要利用監(jiān)管器本地定位。來自所有客戶的通信量通過這一個簡單緩沖器來服務(wù)。
[0130]隨著FIFO緩沖器的填充，隊列長度q(t)增加。諸如較早描述的RED算法的活動隊列管理(AQM)處理保持隊列長度的移動平均值qave，并且丟棄包的增加比例。圖3例示了RED算法，作為使用隊列長度的平均測量的示例功能，以確定針對每一個抵達包的丟棄概率p(t)。
[0131]如果該FIFO緩沖器變得擁塞，則每當必須丟棄的包抵達時，AQM功能內(nèi)的計量器計數(shù)包的尺寸，并且將該丟棄歸因于發(fā)送其的客戶的令牌桶。這通過從客戶桶去除和它們在FIFO緩沖器處丟棄的字節(jié)數(shù)量相同的令牌來進行。因此，客戶i的桶將按速率Vi = PiYi排放，其中，yi是客戶i的通過監(jiān)管器允許的比特率，而Pi是FIFO緩沖器處的丟失概率。對于隨機丟棄來說，Pi對于所有客戶來說一樣，因此，可以說，Pi = P和Vi = PyiO這確?？蛻舻耐鞍磁c它們在本地隊列擁塞期間貢獻的容量成比例的速率排放。
[0132]在其它方面，該令牌桶監(jiān)管器通常對應(yīng)于已經(jīng)描述的IBCTB監(jiān)管器(圖1b)。每一個客戶i的桶都以速率Wi填充擁塞令牌。而且，如果桶的水平Cli降落至零，則從客戶最近抵達的通信量被丟棄，直到它們的桶被新令牌充分再裝滿為止。
[0133]為利用該方法獲得全部有效性，該監(jiān)管器應(yīng)當定位在網(wǎng)絡(luò)中出現(xiàn)擁塞的點處。ConEx和ECN允許包向監(jiān)管器運送擁塞信息，其可以定位在網(wǎng)絡(luò)的“客戶邊緣”處的控制點中。在不存在諸如ConEx的協(xié)議時，監(jiān)管器通常必須定位在擁塞裝置本身處。如果網(wǎng)絡(luò)中存在多個擁塞點，則更難于將監(jiān)管器定位在所有這些點處，因為與一個客戶相關(guān)聯(lián)的一個填充率必須充當針對用于該客戶的全部擁塞令牌桶的共享饋給(每一個位置處一個)。
[0134]根據(jù)另選實施方式，可以通過將本發(fā)明實施方式與分布式擁塞監(jiān)管器技術(shù)(如國際申請W02011/045553中概述的技術(shù))相組合來實現(xiàn)分布式令牌填充。盡管該使其可以在不需要部署任何帶內(nèi)擁塞信令的情況下來部署擁塞監(jiān)管，但必需具有一種用于從中心源向所有監(jiān)管器分配令牌的機制。
【專利附圖】

【附圖說明】
[0135]下面，參照附圖，對本發(fā)明的優(yōu)選實施方式進行描述，其中:
[0136]圖1a例示了已知為“令牌桶監(jiān)管”的技術(shù)；
[0137]圖1b例示了將被稱為“帶內(nèi)擁塞令牌桶監(jiān)管”的技術(shù)；[0138]圖1c例示了已知為“加權(quán)公平排隊”的技術(shù)；
[0139]圖2例示了根據(jù)本發(fā)明優(yōu)選實施方式使用的、將被稱為“帶外擁塞令牌桶監(jiān)管”的技術(shù)；
[0140]圖3例示了可以被用于確定來自FIFO緩沖器的包丟棄概率的示例性活動隊列管理(AQM)功能；
[0141]圖4例示了用于通過計量要丟棄的途中包而以針對現(xiàn)有硬件的最小修改來實現(xiàn)“帶外擁塞令牌桶監(jiān)管器”的可能方法；以及
[0142]圖5例示了基于與真實FIFO緩沖器相關(guān)聯(lián)的虛擬隊列的“帶外擁塞令牌桶監(jiān)管器”的變型例。
【具體實施方式】
[0143]具體參照圖2，對根據(jù)優(yōu)選實施方式的方法進行以下描述。
[0144]圖2所示示例性實施方式將用于說明帶外擁塞令牌桶(OOBCTB)監(jiān)管器怎樣工作。
[0145]1、分類:當一包抵達監(jiān)管器時，分類器(監(jiān)管器內(nèi)未示出的子功能)確定該包關(guān)聯(lián)那個客戶賬戶i，并由此確定該包與哪個令牌桶i關(guān)聯(lián)。其可以通過下面步驟來進行:檢查鏈接層源地址或虛擬 局域網(wǎng)(VLAN)標識符標志，以確定該包從哪個(可能是虛擬的)線路抵達，或者其可以從其它客戶的物理獨特線路抵達，以使其可以直接單獨與一個客戶相關(guān)聯(lián)。
[0146]2、令牌填充:桶i被持續(xù)填充的時間\將按與該桶相關(guān)聯(lián)的結(jié)構(gòu)存儲。確定從那時至現(xiàn)在時間tn?的經(jīng)過時間，Ati = tn0W-tiO接著,將tn?存儲為新的tp將多個令牌添加至等于AtiWi的桶，其中，Wi是針對該桶的定約填充率(也利用桶存儲)。然而，填充不能多于桶最大深度Ci。由此,新的桶水平為(Ii — η?η((^，(^+AtiWi)
[0147]3、監(jiān)管:相關(guān)擁塞令牌桶的水平Cli與包的字節(jié)尺寸Si相比較。如果該水平足夠大，gp，Cli≥Si,則該包被允許經(jīng)過。另外，如果該水平較小，Cl^si,則丟棄該包。
[0148]L入隊:讀取FIFO緩沖器中的隊列長度，以確定是否可以將該包入隊。諸如RED的活動隊列管理算法被用于確定該包是否應(yīng)當根據(jù)平滑隊列長度在概率上丟棄。如果該算法決定在緩沖器中將該包入隊，則不需要進一步動作，并且處理返回至步驟1，以針對下一包。
[0149]5、計暈和令牌排放:如果AQM算法決定丟棄包，則計量所丟棄包的字節(jié)尺寸si，并且從關(guān)聯(lián)令牌桶排放(減去)等于該計量的多個令牌，其條件是，桶深度不能趨負。即，新的桶水平Cli — max (O, (I1- Si)。該處理針對下一個包返回至步驟I。
[0150]應(yīng)注意到，在該優(yōu)選實施方式中，F(xiàn)IFO緩沖器處的丟棄導(dǎo)致令牌桶排放，而監(jiān)管器處的丟棄不會。優(yōu)選的是，因為另外監(jiān)管器處的丟棄既因空令牌桶導(dǎo)致，也導(dǎo)致令牌桶為空，從而產(chǎn)生惡性循環(huán)，其對于用戶來說，一旦它們的桶已經(jīng)為空，就難于恢復(fù)正常服務(wù)。
[0151]而且注意到，在該優(yōu)選實施方式中，監(jiān)管步驟先于入隊和計量步驟。另外，如果監(jiān)管在入隊之后，則隊列管理算法將去除正好夠的通信量，以保持隊列足夠短，那么監(jiān)管將不必去除更多通信量。這通常會保持線路空閑，其被稱作非工作保存，或簡稱為利用不足。
[0152]改為在監(jiān)管器處的丟棄應(yīng)當防止甚至將契約外通信量考慮用于排隊，因而契約外通信量將不改變因已經(jīng)被允許經(jīng)過緩沖器的契約內(nèi)通信量而造成多少擁塞的令牌桶測量。[0153]盡管如此，對于另選實施方式來說，存在按與上面列出的優(yōu)選次序不同的次序跟隨上述五個步驟的某一范圍。例如，填充步驟可以在分類之后的任何階段進行，而不必緊接其后。
[0154]還參照圖2的數(shù)字實施例情況將用于說明OOBCTB監(jiān)管器對不同業(yè)務(wù)流的影響。在這個實施例中，變量Xi指示客戶i的全部通信量的抵達比特率，而yi指示離開監(jiān)管器的同一用戶通信量的比特率。
[0155]考慮到由許多客戶共享的速率為Y = lGb/s的線路，將聚焦在該多個客戶中兩個上。設(shè)想在FIFO緩沖器正必需丟棄I %的包(P = 1% )時的短暫時段At1 = 50ms，并且第一客戶在該時間按比特率的20%傳遞(yi = X1 = 20% *lGb/s = 200Mb/s)。因而，1%字節(jié)中的20%將被歸因為由客戶I造成的擁塞。而如果第二客戶已經(jīng)按I %擁塞水平的初期跡象快速縮減其速率，比方說，容量的0.5% (y2 = X2 = 0.5% *lGb/s = 5Mb/s),則超過當針對所有客戶的擁塞水平P為1%時的50ms時段，I %擁塞字節(jié)中的0.5%將歸因于該第二客戶。由此，從每一個客戶桶排放的令牌超過該時段#1:
[0156]Vi；! = Δ
[0157]= Δ Yi [0158]V1 ! = 0.05s*l % *lGb/s*20% = IOOkb
[0159]V2,! = 0.05s*l% *lGb/s*0.5%= 2.5kb
[0160]下面，設(shè)想，對于更長時段Λ t2 = 4秒鐘來說，丟失概率P下降至0.001 %，并且第二客戶快速增加其速率直至容量的50%，顯著超過第一客戶傳遞的容量。那么:
[0161]Vi 2 = At2P Yi
[0162]V1；2 = 4s*0.001 % *lGb/s*20% = 8kb
[0163]V2 2 = 4s*0.001% *lGb/s*80%= 32kb
[0164]因此,超過整個4.05s時段:
[0165]從客戶I 的桶排放 V1 = V1； !+Vlj 2 = 100kb+8kb = 108kb
[0166]從客戶2 的桶排放 V2 = V2； !+V2j 2 = 2.5kb+32kb = 34.5kb
[0167]在組合的這兩個時段期間，通過每一個客戶傳遞的容量為:
[0168]X1 ! = 0.05s*lGb/s*20% = IOMb
[0169]X2 ! = 0.05s*lGb/s*0.5%= 0.25Mb
[0170]X12 = 4s*lGb/s*20%= 800Mb
[0171]X2 2 = 4s*lGb/s*50%= 2，OOOMb
[0172]X, = X1 ,+X1 o = 810Mb
[0173]X2 = X2, !+X2j2 = 2.000.25Mb
[0174]盡管第二客戶傳遞了接近3倍的第一客戶的容量，但其在貢獻1/3擁塞貢獻的同時實現(xiàn)該傳遞量，因此，其擁塞令牌桶按比第一客戶的1/3速率更慢地排放。這是因為其通過響應(yīng)于擁塞急劇縮減其速率，并且只要該擁塞減退將再次快速增加速率來快速響應(yīng)。
[0175]下面，設(shè)想兩個客戶與網(wǎng)絡(luò)運營商具有契約，其允許它們造成20kb/s的擁塞，即，W1 = W2 = 20kb/so
[0176]如果上述行為在隨后時段持續(xù)，則客戶的令牌桶將該分別按下面速率繼續(xù)排放:
[0177]V1 = 108kb/4.05s, ^ 26.7kb/s,[0178]V1 = 34.5kb/4.05s, ^ 8.5kb/s,
[0179]由此，第二客戶的令牌桶比其填充率20kb/s更快地排放。因此，該桶將最終變空，并且關(guān)聯(lián)監(jiān)管器將開始限制第一客戶可以貢獻的通信量Y1低至比其發(fā)送的少得多，yi〈〈Xl。
[0180]此時，即使第二客戶傳遞更加多的容量，其桶也將保持為滿，因為其正在比定約填充率更慢地排放擁塞令牌。這是因為第二客戶高度響應(yīng)于短暫的擁塞時段，而第一客戶并未響應(yīng)。因此，第二客戶根本不受監(jiān)管器限制，y2 = x2。
[0181]監(jiān)管器一縮減yi，也就縮減歸因于客戶I的緩沖器中擁塞的比例部分(并且擁塞P也很可能縮減，盡管取決于每一個別人的行為)。這將根據(jù)客戶I的令牌桶縮減排放率V1=P Y1，其轉(zhuǎn)過來允許該桶比其排放更快地填充。這又再一次縮減或消除針對客戶I的監(jiān)管器丟棄。在長期運行時，客戶I的吞吐量將受限于其不能導(dǎo)致比其擁塞定約速率更多的這種速率。
[0182]奪型例
[0183]|H規(guī)令牌填充:令牌填充步驟(上述步驟2)不需要根據(jù)與令牌桶i相關(guān)聯(lián)的包的抵達來觸發(fā)。代替地，其可以根據(jù)針對按規(guī)則間隔Ati發(fā)生的計時器中斷來觸發(fā)。在每一個間隔之后，將多個令牌添加至等于AtiWi的桶，其中，Wi是針對該桶的定約填充率。至于上述異步(包觸發(fā))令牌填充方法，該桶不能填充大于其最大深度Ci,由此，新的令牌水平仍為Cli — min (Ci, Cli+ Δ tjWj),唯一的差別是Δ tj在該情況下是常數(shù)。
[0184]ECN和丟棄:該緩沖器可以ECN使能。在擁塞期間，其將標記而非丟棄指示其來自ECN能力傳輸(RCT)的任何通信量。該令牌排放步驟將從桶中減去和包的字節(jié)尺寸一樣多的令牌，無論該包被丟棄 還是ECN標記來指示擁塞。然而，如果包既未被標記也未被丟棄，則不排放令牌。
[0185]注意帶外與帶內(nèi)計量方法之間的重要區(qū)別。帶內(nèi)計量器使用抵達包上的預(yù)先存在標記，來確定是否從桶中排放令牌。而帶外計量器僅因局部擁塞而根據(jù)局部隊列尺寸來排放桶。因而，其將ECN標記應(yīng)用為輸出信號。在帶內(nèi)情況下，ECN標記向處理提供輸入。而在帶外情況下，ECN標記僅僅是輸出，而真正地，它們事實上僅是可選輸出。
[0186]這就是為什么計量技術(shù)被稱作帶外的緣故；因為計量量不根據(jù)包內(nèi)的信令來確定。相反地，計量量從緩沖器向令牌桶信令通知，而不利用數(shù)據(jù)包來運送信號。典型地講，這些信號將通過機器的內(nèi)部總線在緩沖器與監(jiān)管器之間運送，這就是為什么它們被稱作帶外的緣故。
[0187]暈化擁寒水平:替代排放擁塞令牌桶取決于二進制擁塞通知(丟棄或標記)，令牌可以根據(jù)每一個包的尺寸和保持為實數(shù)的緩沖器擁塞水平來排放。例如，包尺寸和擁塞水平可以相乘，以確定排放多少令牌。
[0188]各種批準:第一實施方式在監(jiān)管情況內(nèi)構(gòu)造，但要點是等于擁塞令牌桶與任何監(jiān)管功能進行組合。監(jiān)管器本身不是主要方面；并且可以使用各種批準，是否與所述監(jiān)管動作一樣、是否與其它先前公開監(jiān)管器一樣，還是不同。有關(guān)所應(yīng)用批準的可能變型例包括但不限于:
[0189]-重新路由契約外通信量
[0190]-延遲契約外通信量
[0191]-破壞契約外通信量，例如，截尾凈荷，但轉(zhuǎn)發(fā)報頭，或許具有契約外指示，該指示對其與包破壞或丟棄的其它原因進行區(qū)分
[0192]-降級契約外通信量的服務(wù)類別，而非丟棄服務(wù)
[0193]在該最后一種情況下，因為監(jiān)管器不去除契約外通信量，所以可按優(yōu)選實施方式的五個步驟的次序允許更多靈活性。例如，監(jiān)管步驟可以跟在入隊步驟和/或計量與排放步驟之后。
[0194]不同擁寒簡檔比較器設(shè)計:令牌桶是一種常規(guī)方法，其用于對歸因于用戶的擁塞簡檔與定約簡檔進行比較，但其不是用于實現(xiàn)這種比較功能的唯一方法。可能變型例包括但不限于:
[0195]-隨著包抵達而填充有令牌并且按恒定速率排放的漏桶。漏桶僅是令牌桶的逆轉(zhuǎn)。其外部行為可以通過進行如下操作來設(shè)置為等同尺寸化令牌桶:在漏桶為滿時觸發(fā)與令牌桶為空時將觸發(fā)動作相同的動作。
[0196]-利用桶的不同組合，如限制填充速率和排放速率兩者的雙令牌桶、單速率三色標記器、雙速率三色標記器等
[0197]-無論何時桶深度低于配置閾值而非所討論包尺寸，都考慮契約外通信量
[0198]-增加計量器認為低于桶水平的契約外通信量低于閾值而非二進制輸入輸出決定的概率
[0199]-利用具有和令牌桶相似結(jié)果的模型，但未內(nèi)部實現(xiàn)為令牌桶
[0200]-根據(jù)用戶的擁塞率與針對該用戶的定約擁塞率之間的差別確定有多少通信量是契約外的測量。
[0201]無批準，僅計暈:第一實施方式在監(jiān)管情況內(nèi)構(gòu)造，但是，如上已經(jīng)指出，這種實施方式的監(jiān)管功能不必不同于先前公開監(jiān)管器的監(jiān)管功能。然而，重要的區(qū)別在于，與根據(jù)擁塞水平觸發(fā)的動作組合使用擁塞令牌桶。例如，擁塞計量技術(shù)可以被用于檢測通信量是否在擁塞契約之外，接著，觸發(fā)管理動作的潛在范圍而非(直接)監(jiān)管，包括(但不限于):
[0202]-觸發(fā)針對運營商的警告
[0203]-觸發(fā)針對客戶的警告消息
[0204]-增加網(wǎng)絡(luò)服務(wù)的使用價格
[0205]-可能為了以下目的計數(shù)契約外通信量的容量:
[0206]-向所計數(shù)容量計取更高使用費
[0207]-排放附加令牌桶，其有可以被設(shè)計成，觸發(fā)監(jiān)管或管理動作
[0208]-觸發(fā)契約內(nèi)罰款條款的應(yīng)用
[0209]-改變排程器的每用戶權(quán)重
[0210]-改變用戶的簡檔或類別
[0211]緩沖器管理變型例:第一實施方式在其中緩沖器使用RED活動隊列管理算法的情況內(nèi)構(gòu)造，但可以使用任何其它算法，包括(但不限于):
[0212]-非隊列平均化
[0213]-簡單閾值
[0214]-用于根據(jù)隊列長度來計算丟棄或標記的概率的不同形狀函數(shù)
[0215]-根本沒有AQM算法(尾部丟棄)
[0216]而且，第一實施方式在使用FIFO緩沖器的情況內(nèi)構(gòu)造，但其它排隊規(guī)范也是合適的，包括(但不限于):
[0217]-作為更復(fù)雜排隊系統(tǒng)的一部分的緩沖器，但作為自身內(nèi)的FIFO
[0218]-加權(quán)排程器如加權(quán)輪循或加權(quán)公平排隊
[0219]-具有不同排程優(yōu)先級的一組緩沖器，但其中，一個緩沖器的丟棄或標記概率取決于其它緩沖器中的隊列尺寸(例如，[Gibbens02])
[0220]分類器變型例:該分類器可以關(guān)聯(lián)每一個包與發(fā)送方、接收方，或保持可向通信量負責的某一其它實體的客戶賬戶。
[0221]與在監(jiān)管情況內(nèi)使用的實施方式有關(guān)地，更可能在通信量已經(jīng)經(jīng)過網(wǎng)絡(luò)之前靠近發(fā)送方來應(yīng)用監(jiān)管。由于通信量已經(jīng)經(jīng)過網(wǎng)絡(luò)，因而靠近接收器丟棄契約外通信量幾乎不對用途提供服務(wù)。源可以響應(yīng)于監(jiān)管器丟棄來縮減其速率，但假設(shè)監(jiān)管器被設(shè)計成標識導(dǎo)致過度擁塞的通信量源，則似乎假定該源總是靈敏地響應(yīng)于監(jiān)管器丟棄是不適合的。
[0222]如果要使用的客戶賬戶是接收器的賬戶，則分類器將典型地使用目的地地址來對每一個包與客戶賬戶進行關(guān)聯(lián)。
[0223]分類器可以關(guān)聯(lián)每一個包與網(wǎng)絡(luò)提供方的賬戶，其又向終端用戶提供服務(wù)，而非對每一個包與每一個終端用戶進行直接關(guān)聯(lián)。網(wǎng)絡(luò)提供方本身可以商業(yè)地提供其服務(wù)，或者其可以是私人企業(yè)，如大學(xué)校園或企業(yè)的網(wǎng)絡(luò)運營商。在這些情況下，服務(wù)vlan(s-vlan)標志可以典型地被用于標識合適用戶賬戶。
[0224]另選的是，與網(wǎng)絡(luò)尋址無關(guān)的標識符可以被用于對每一個包與正確的客戶賬戶進行關(guān)聯(lián)。例如，可以使用點對點協(xié)議(PPP)中的會話標識符，或者加密生成的標識符或標識符序列。
[0225]AE:在優(yōu)選實施方式中，丟棄決定在入隊處理其中針對包進行。這不是旨在排除另選排隊布置，其中，由于包出列，因而作出丟棄決定，或者如果從隊列中部丟棄包，則作出丟棄決定。
[0226]而且，丟棄決定可以基于虛擬隊列尺寸來進行，該虛擬隊列對抵達真實隊列的包的尺寸進行計數(shù)，但概念上比真實隊列更慢地排放。
[0227]在一另選實施方式中，隊列管理算法可以內(nèi)部地朝著內(nèi)部丟棄功能重新路由包，而非立即丟棄它們(參見圖4)。因而，與合適用戶賬戶相關(guān)聯(lián)的令牌桶可以計量至該內(nèi)部丟棄功能途中的每一個包，以便排放適于該包尺寸的量。該另選實施方式具有根據(jù)針對計量功能的變化去耦針對隊列管理功能的變化的優(yōu)點。AQM功能不必修改成包括每客戶計量，其僅需要改變或朝著內(nèi)部丟棄功能重新路由包，而非丟棄它們本身。在特定現(xiàn)有實現(xiàn)中，這種去耦可以允許使用預(yù)先存在的計量功能，而不需要改變，如果該功能按難于改變的硬件具體實施，則其可能是有利的。
[0228]虛擬隊列:該優(yōu)選實施方式需要丟棄包，以便針對每一個客戶歸因擁塞。在一另選實施方式中，包可以按虛擬隊列虛擬地丟棄，而非實際丟棄。虛擬隊列不緩沖包，其僅是跟蹤在線路速率稍微慢于真實線路的情況下而形成包的虛擬隊列長度的計數(shù)器。圖5示出了具有輸出速率Y的真實隊列，和具有稍低的輸出速率(1-ε)Υ的虛擬隊列，其中ε〈〈1。抵達真實隊列的包的長度被添加至表示虛擬隊列的計數(shù)器。
[0229]該另選實施方式非常類似于所述優(yōu)選實施方式，所不同的是排放來自每一個客戶桶的令牌的計量器對作用于抵達虛擬隊列而非真實隊列的復(fù)制包長度的活動隊列管理處理進行監(jiān)測。如果聚合輸入速率接近虛擬輸出速率(1- ε )Υ，則虛擬隊列生長。隨著虛擬隊列生長，隨著虛擬包抵達虛擬隊列而選擇虛擬包的概率增加。計量器將這種選定包的尺寸歸因于相關(guān)令牌桶，并從令牌桶減去該包尺寸，其本身也僅為一計數(shù)器。在其它方面，該另選實施方式按和所述優(yōu)選實施方式相同的方式工作。
[0230]標準化權(quán)重:第一實施方式已經(jīng)描述為好像每一個擁塞令牌桶的填充速率被設(shè)置成已知固定量。
[0231]相反的是，根據(jù)該系統(tǒng)的另一方面，填充速率可以改變。例如，該填充速率可以是針對多個不同目的(例如處理和存儲以及帶寬分配)分配的較大容差的一部分。因而，可用于帶寬分配的容差量根據(jù)用于其它目的的量改變，并且根據(jù)用于在其構(gòu)成部件之間劃分較大分配的算法改變。
[0232]另選的是，系統(tǒng)可以被設(shè)計成其中僅權(quán)重的相對尺寸需要被設(shè)置，而它們的絕對值不需要設(shè)置。另外，一參數(shù)需要被設(shè)置成，設(shè)置應(yīng)當旨在被視為契約外的客戶的比例，-怎樣有效地將強力監(jiān)管聚焦在幾個客戶上。
[0233]接著，內(nèi)部地，該系統(tǒng)可以成比例地調(diào)節(jié)所有權(quán)重，以便保持大部分隊列的填充水平火靠近它們各自桶的中部，而允許監(jiān)管以聚焦于配置很少的客戶，這些客戶相對于他們的定約份額貢獻最大比例部分的擁塞。
[0234]不只是包:本發(fā)明實施方式還可以等同地應(yīng)用于按數(shù)據(jù)報、幀或其它離散數(shù)據(jù)單元抵達的通信量。
[0235]分布式填充速率:另選實施方式可以通過將本發(fā)明的恰當實施方式與分布式擁塞監(jiān)管器技術(shù)(如國際申請W02011/045553中概述的技術(shù))相組合來實現(xiàn)或允許分布式令牌填充。盡管這樣使其可以在不需要部署任何帶內(nèi)擁塞信令的情況下來部署擁塞監(jiān)管，但通常必需具有一種用于從中心源向所有監(jiān)管器分配令牌的機制。
[0236]分布式緩沖器和/或計暈器:第一實施方式已經(jīng)與其中緩沖器和計量器處于和令牌桶相同的機器內(nèi)的情況有關(guān)地進行了描述。另選實施方式將按其中更便于將實際緩沖器從令牌桶和監(jiān)管器去除的情況來分布這些部件。例如，分布式布置包括(但不限于)下列:
[0237]-在DOCSIS(有線數(shù)據(jù)傳輸系統(tǒng))有線系統(tǒng)中，線纜容量被劃分成利用時分復(fù)用分隔的信道。針對稱作有線調(diào)制解調(diào)器終端服務(wù)器(CMTS)的整個混合同軸光纖的居中的節(jié)點利用帶外消息的系統(tǒng)來判斷針對每一個數(shù)據(jù)信道的接入。按上游方向，在共享有線網(wǎng)絡(luò)的入口上，存在多個緩沖器，每一個有線調(diào)制器中至少存在一個緩沖器。由此，與圖2所示單一 FIFO緩沖器不同，該系統(tǒng)包含許多緩沖器，每一個都保持邏輯分離的通信量隊列，但全部等待進入邏輯上按時隙劃分的單一物理源。
[0238]盡管不如圖2的簡單的單一緩沖器那樣直接，但CMTS可以根據(jù)針對用于發(fā)送數(shù)據(jù)的一時隙的未履行或延期請求的數(shù)量來確定每一個客戶對擁塞的貢獻。因而，可以將該計量擁塞容量用于排放令牌桶。該系統(tǒng)的其余部分可以對應(yīng)于已經(jīng)描述的內(nèi)容。
[0239]-無源光纖網(wǎng)絡(luò)(PON)按與DOSIS有線系統(tǒng)類似的方式使用時分復(fù)用。當然，盡管PON在許多細節(jié)上不同于DOCSIS有線網(wǎng)絡(luò)，但上述針對DOCSIS的方法直接轉(zhuǎn)變成PON情況。
[0240]-在蜂窩系統(tǒng)中，無線頻譜是共享鏈路，概念上類似于DOCSIS系統(tǒng)的共享線纜。在UMTS和LTE中，該頻譜分離成利用碼分多址(CDMA)的多個信道。類似于線纜，每一個移動終端(手機)都具有緩沖器，以排隊等待被允許通過無線電頻譜向上游傳遞的數(shù)據(jù)。該無線電網(wǎng)絡(luò)控制器(RNC)針對有線網(wǎng)絡(luò)中的CMTS服務(wù)類似功能，判斷針對作為無線電資源控制系統(tǒng)中心的發(fā)送信道的請求。
[0241]此外，確定每一個客戶的擁塞貢獻不如圖2的簡單單一緩沖器那樣直接，但其概念上類似于線纜情況，并且在高水平下，概念上類似于單一緩沖器情況。
[0242]按下游方向，所有這些系統(tǒng)都包含居中緩沖器，并且可以針對圖2描繪的更簡單請求建模。
[0243]不只是帶寬:所述優(yōu)選實施方式已經(jīng)按這樣的情況進行了描述，即，所共享資源是通信鏈路的帶寬并且排隊以使用該資源的項目是包。下面，另選實施方式的非排它列表也是可以的，其中，本發(fā)明構(gòu)思被應(yīng)用于其它共享資源和其它排隊項目:
[0244]-針對使用調(diào)用服務(wù)器的調(diào)用處理資源的請求
[0245]-針對使用共享計算機的處理資源的請求
[0246]-針對使用共享存儲器池(例如，磁盤)的存儲資源的請求
[0247]-針對使用共享工作流系統(tǒng)中的處理資源的請求，其中，該處理資源可以表示機械或人操作功能，而不只是計算功能(例如，共享機器、現(xiàn)場工程師、呼叫中心工作人員等)。
[0248]-利用道路運輸系統(tǒng)的車輛
[0249]-使用能量供應(yīng)網(wǎng)絡(luò)的單元，例如提供電力或天然氣。
[0250]變型例的組合:進一步的另選實施方式可以通過組合所述優(yōu)選實施方式的一部分的變型例與另一部分的變型例來創(chuàng)建。例如，該基于虛擬隊列的實施方式(圖5)可以與其中AQM功能朝著丟棄功能重新路由包的實施方式(圖4)而非AQM內(nèi)的計量相組合?；蛘?，該虛擬隊列變型例可以與ECN變型例相組合。在另一個實施例中，分布式填充速率變型例可以與向工作流系統(tǒng)而非包轉(zhuǎn)發(fā)系統(tǒng)應(yīng)用的變型例相組合。
[0251]這些變型例的許多組合也是可以的，因而，這幾個實施例不是旨在表示詳盡列表。
[0252]參考文獻
[0253][Gibbens02]:Gibbens, R.J.&Kelly, F.P., "On Packet Marking at PriorityQueues, "IEEE Transactions on Automatic Control47 (6): 1016—1020 (June2002)
【權(quán)利要求】
1.一種歸因針對相應(yīng)用戶寄存器的共享資源的擁塞貢獻的方法，所述資源可操作以對服務(wù)的請求提供服務(wù)，多個所述請求中的每一個都具有與請求相關(guān)聯(lián)的、指示所述請求與多個用戶寄存器中的哪一個寄存器相關(guān)聯(lián)的用戶指示；所述方法包括以下步驟: 根據(jù)每一個相應(yīng)用戶寄存器的預(yù)定特征重復(fù)地更新該每一個相應(yīng)用戶寄存器； 根據(jù)從共享所述資源的用戶接收的請求更新多用戶擁塞測量； 并且針對接收的請求: -根據(jù)與請求相關(guān)聯(lián)的用戶指示來標識與所述請求相關(guān)聯(lián)的用戶寄存器； -根據(jù)更新后的所述多用戶擁塞測量來更新關(guān)聯(lián)的所述用戶寄存器的狀態(tài)；以及 -根據(jù)關(guān)聯(lián)的所述用戶寄存器的更新后的狀態(tài)來確定可歸因于關(guān)聯(lián)的所述用戶寄存器的共享資源的擁塞貢獻。
2.根據(jù)權(quán)利要求1所述的方法，其中，所述資源可操作以對數(shù)據(jù)網(wǎng)絡(luò)內(nèi)的服務(wù)的請求提供服務(wù)。
3.根據(jù)權(quán)利要求1或2所述的方法，其中，所述請求包括數(shù)據(jù)單元。
4.根據(jù)權(quán)利要求3所述的方法，其中，關(guān)于數(shù)據(jù)單元的所述用戶指示是以下中的一個或更多個的指示:所述數(shù)據(jù)單元的發(fā)送方；所述數(shù)據(jù)單元的一個或更多個希望接收方；或者對于發(fā)送和/或接收所 述數(shù)據(jù)單元有責任的實體。
5.根據(jù)權(quán)利要求3或4所述的方法，其中，所請求的所述服務(wù)包括經(jīng)由一個或更多個數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)所述數(shù)據(jù)單元。
6.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，更新的所述多用戶擁塞測量與所述接收的請求分開傳送，由此允許更新關(guān)聯(lián)的所述用戶寄存器的狀態(tài)。
7.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，關(guān)聯(lián)的所述用戶寄存器的狀態(tài)按取決于為服務(wù)的所述請求提供服務(wù)所需的所述資源的量的測量的量和取決于所述多用戶擁塞測量的量來更新。
8.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，更新所述多用戶擁塞測量的步驟包括以下步驟:根據(jù)所述資源是否對服務(wù)的所述請求提供服務(wù)，來更新所述多用戶擁塞測量。
9.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，針對已經(jīng)被拒絕的服務(wù)的請求被重新用作用于傳送更新后的所述多用戶擁塞測量的手段，由此，允許更新關(guān)聯(lián)的所述用戶寄存器的狀態(tài)。
10.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，所述多用戶擁塞測量依靠根據(jù)接收到的所述服務(wù)的請求所更新的多用戶寄存器本身的狀態(tài)來更新，由此模擬所述接收到的請求應(yīng)當怎樣由與所述共享資源相比能力較差的資源提供服務(wù)。
11.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，每一個相應(yīng)用戶寄存器按下列方式中的一個或兩個來更新: -根據(jù)該用戶寄存器的預(yù)定特征周期性地進行更新；和 -在接收到具有指示與該用戶寄存器關(guān)聯(lián)性的用戶指示的請求的情況下，根據(jù)該用戶寄存器的預(yù)定特征進行更新。
12.根據(jù)前述權(quán)利要求中的任一項所述的方法，其中，每一個用戶寄存器都包括實現(xiàn)令牌桶或漏桶功能的一個或更多個模塊。
13.根據(jù)前述權(quán)利要求中的任一項所述的方法，所述方法還包括以下步驟:與對與用戶寄存器相關(guān)聯(lián)的請求提供服務(wù)有關(guān)地和/或與向與用戶寄存器相關(guān)聯(lián)的用戶提供的服務(wù)有關(guān)地，根據(jù)這樣確定的擁塞貢獻來進行服務(wù)確定。
14.根據(jù)權(quán)利要求13所述的方法，所述方法還包括以下步驟:根據(jù)所述服務(wù)確定為服務(wù)的請求提供服務(wù)，或者發(fā)送所述服務(wù)確定的指示，由此使得能夠根據(jù)所述服務(wù)確定來為服務(wù)的請求提供服務(wù)。
15.用于執(zhí)行根據(jù)前述權(quán)利要求中的任一項所述的方法的裝置。
【文檔編號】H04L12/801GK103999414SQ201280059258
【公開日】2014年8月20日 申請日期:2012年9月27日 優(yōu)先權(quán)日:2011年9月30日
【發(fā)明者】羅伯特·約翰·布里斯科, 安德列·亞索伯拉, 阿諾·雅凱 申請人:英國電訊有限公司