用于多徑流式傳輸?shù)幕趂ec的可靠傳輸控制協(xié)議的制作方法
【專利說明】用于多徑流式傳輸?shù)幕贔EC的可靠傳輸控制協(xié)議
[0001]本申請要求享有于2013年1月17日提交的美國臨時(shí)申請序列號N0.61/753,884以及于2013年5月1日提交的美國臨時(shí)申請序列號N0.61/818，106的利益，上述每份申請的全部內(nèi)容以引用方式并入本文。
技術(shù)領(lǐng)域
[0002]本公開內(nèi)容涉及媒體數(shù)據(jù)的傳輸。
【背景技術(shù)】
[0003]設(shè)備可以使用多個(gè)路徑和低延時(shí)處置，通過數(shù)據(jù)通信網(wǎng)絡(luò)來執(zhí)行數(shù)據(jù)在端系統(tǒng)之間的快速傳輸。很多數(shù)據(jù)通信系統(tǒng)和高層數(shù)據(jù)通信協(xié)議提供可靠數(shù)據(jù)傳輸?shù)谋憷ㄐ盘崛?，并提供速率控制，即，它們基于網(wǎng)絡(luò)狀況自動(dòng)地調(diào)整它們的分組傳輸速率。諸如普遍存在的傳輸控制協(xié)議(TCP)之類的依據(jù)較低層的分組化數(shù)據(jù)傳輸?shù)乃鼈兊膫鹘y(tǒng)底層實(shí)施方式遭受以下狀況中的至少一種狀況發(fā)生:(a)發(fā)送方和接收方之間的連接具有較大的往返時(shí)間(RTT) ;(b)數(shù)據(jù)的量很大，并且網(wǎng)絡(luò)遭受突發(fā)和瞬時(shí)丟失。
[0004]—種廣泛使用的可靠傳輸協(xié)議是傳輸控制協(xié)議(TCP)。TCP是一種普遍使用的具有確認(rèn)機(jī)制的點(diǎn)到點(diǎn)分組控制方案。當(dāng)發(fā)送方和接受方之間存在很少的丟失，并且發(fā)送方和接受方之間的RTT很小時(shí)，TCP很好地適用于一對一的可靠通信。然而，當(dāng)甚至存在非常少的丟失時(shí)，或者當(dāng)發(fā)送方和接受方之間存在任何顯著的延時(shí)時(shí)，TCP的吞吐量將急劇地下降。
[0005]通過使用TCP，發(fā)送方發(fā)送有序分組，接受方對每個(gè)分組的接收進(jìn)行確認(rèn)。如果一個(gè)分組丟失，則不向發(fā)送方發(fā)送確認(rèn)，并且基于后續(xù)接收的分組的接收或者基于超時(shí)，發(fā)送方將重新發(fā)送該分組。在使用諸如TCP之類的協(xié)議的情況下，這種確認(rèn)范式允許在不具有整體失敗的情況下，發(fā)生分組丟失，這是由于響應(yīng)于確認(rèn)的缺失或者響應(yīng)于來自接受方的顯式請求，可以僅對丟失的分組進(jìn)行重傳。
[0006]TCP提供了可靠性控制和速率控制二者。也就是說，實(shí)現(xiàn)TCP的設(shè)備確保將所有原始數(shù)據(jù)都傳送到接收方，并基于諸如擁塞和分組丟失之類的網(wǎng)絡(luò)狀況來自動(dòng)地調(diào)整分組傳輸速率。在使用TCP的情況下，可靠性控制協(xié)議和速率控制協(xié)議是相互纏繞而不可分離的。此外，根據(jù)增加的RTT和分組丟失的TCP的吞吐量性能遠(yuǎn)不是最優(yōu)的。

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

[0007]概括地說，本發(fā)明描述了與應(yīng)用于在多個(gè)并行網(wǎng)絡(luò)路徑上發(fā)送的數(shù)據(jù)的前向糾錯(cuò)(FEC)有關(guān)的技術(shù)。在一個(gè)例子中，可以通過把要傳輸?shù)臄?shù)據(jù)組織成數(shù)據(jù)塊，可靠地從發(fā)送方向接收方傳輸數(shù)據(jù)，其中，每個(gè)數(shù)據(jù)塊包括多個(gè)編碼單元?？梢栽诙鄠€(gè)路徑上從發(fā)送方向接收方發(fā)送針對第一數(shù)據(jù)塊的編碼單元，即，第一數(shù)據(jù)塊的一些編碼單元在一個(gè)路徑上進(jìn)行發(fā)送，而第一數(shù)據(jù)塊的其它編碼單元在第二路徑上進(jìn)行發(fā)送等等。發(fā)送方可以檢測接收方對編碼單元的接收的確認(rèn)。在發(fā)送方處，可以檢測接收方從針對第一數(shù)據(jù)塊的已發(fā)送的編碼單元中接收到第一數(shù)據(jù)塊的足夠的編碼單元，以在接收方處恢復(fù)該第一數(shù)據(jù)塊的概率，并且可以將該概率與門限概率進(jìn)行測試比對，以確定是否滿足了預(yù)定的測試條件。在測試的步驟之后，并在發(fā)送方接收到接收方處對第一數(shù)據(jù)塊的恢復(fù)的確認(rèn)之前，當(dāng)滿足預(yù)定的測試條件時(shí)，發(fā)送方可以在多個(gè)路徑上從該發(fā)送方發(fā)送第二數(shù)據(jù)塊的編碼單元。在一些例子中，在已經(jīng)發(fā)送了足夠數(shù)量的第一塊的編碼單元以便接收方恢復(fù)第一塊之前，發(fā)送方可以發(fā)送第二塊的編碼單元，因而發(fā)送方可以在發(fā)送了針對第二塊的至少一些編碼單元之后，發(fā)送針對第一塊的另外的編碼單元。此外，在一個(gè)塊完全形成之前，發(fā)送方就可以向接收方發(fā)送該塊的編碼單元。在一些例子中，預(yù)定的測試條件是將所述概率與門限概率進(jìn)行比較，當(dāng)該概率大于門限概率時(shí)，確定滿足了預(yù)定的測試條件。
[0008]在一些例子中，隨著每個(gè)塊的生成，發(fā)送方還可以動(dòng)態(tài)地確定各個(gè)塊的大小或者持續(xù)時(shí)間，確定在生成這些塊中的數(shù)據(jù)時(shí)所按照的速率、以及確定在所述多個(gè)路徑中的各個(gè)路徑上向接收方發(fā)送編碼單元時(shí)所按照的速率。
[0009]在一個(gè)例子中，一種計(jì)算機(jī)可讀存儲介質(zhì)上存儲有指令，其中當(dāng)這些指令被執(zhí)行時(shí)，使得客戶端設(shè)備的處理器經(jīng)由多個(gè)并行網(wǎng)絡(luò)路徑從服務(wù)器設(shè)備接收經(jīng)前向糾錯(cuò)的數(shù)據(jù)，確定這些網(wǎng)絡(luò)路徑中的每個(gè)網(wǎng)絡(luò)路徑上的數(shù)據(jù)的丟失率，以及向服務(wù)器設(shè)備發(fā)送用于表示這些網(wǎng)絡(luò)路徑中的每個(gè)網(wǎng)絡(luò)路徑上的數(shù)據(jù)的丟失率的數(shù)據(jù)。
[0010]在另一例子中，一種計(jì)算機(jī)可讀存儲介質(zhì)上存儲有指令，其中當(dāng)這些指令被執(zhí)行時(shí)，使得服務(wù)器設(shè)備的處理器經(jīng)由多個(gè)并行網(wǎng)絡(luò)路徑，向客戶端設(shè)備發(fā)送經(jīng)前向糾錯(cuò)的數(shù)據(jù)，從客戶端設(shè)備接收用于表示在所述多個(gè)網(wǎng)絡(luò)路徑中的每個(gè)網(wǎng)絡(luò)路徑上發(fā)送的數(shù)據(jù)的丟失率的數(shù)據(jù)，以及基于用于表示所述丟失率的所述數(shù)據(jù)，修改在所述并行網(wǎng)絡(luò)路徑上針對后續(xù)數(shù)據(jù)傳輸發(fā)送的經(jīng)前向糾錯(cuò)的數(shù)據(jù)的量。
[0011]在附圖和下面的說明書中闡述了一個(gè)或多個(gè)例子的細(xì)節(jié)。根據(jù)該描述和附圖，以及根據(jù)權(quán)利要求書，其它特征、目的和優(yōu)點(diǎn)將變得顯而易見。
【附圖說明】
[0012]圖1是可以使用本公開內(nèi)容的技術(shù)的示例性網(wǎng)絡(luò)、發(fā)送方端系統(tǒng)和接收方端系統(tǒng)的框圖。
[0013]圖2是模塊化可靠傳輸協(xié)議架構(gòu)以及使用這樣的協(xié)議進(jìn)行操作的相關(guān)系統(tǒng)的說明。
[0014]圖3是發(fā)送方的基于FEC的可靠性控制協(xié)議架構(gòu)以及使用這樣的協(xié)議進(jìn)行操作的相關(guān)系統(tǒng)的例子。
[0015]圖4是接收方的基于FEC的可靠性控制協(xié)議架構(gòu)以及使用這樣的協(xié)議進(jìn)行操作的相關(guān)系統(tǒng)的例子。
[0016]圖5示出了可以由實(shí)現(xiàn)TF可靠性控制協(xié)議的系統(tǒng)使用的一組可能的格式。
[0017]圖6是描繪了實(shí)現(xiàn)發(fā)送方TF可靠性控制協(xié)議的系統(tǒng)的邏輯的流程圖。
[0018]圖7是描繪了實(shí)現(xiàn)接收方TF可靠性控制協(xié)議的系統(tǒng)的邏輯的流程圖。
[0019]圖8是活動(dòng)塊的說明。
[0020]圖9是可以由交織式可靠性控制協(xié)議使用的一組可能的格式的說明。
[0021]圖10是實(shí)現(xiàn)基本發(fā)送方交織式可靠性控制協(xié)議的系統(tǒng)的邏輯的說明性例子。
[0022]圖11是實(shí)現(xiàn)基本接收方交織式可靠性控制協(xié)議的系統(tǒng)的邏輯的說明性例子。
[0023]圖12是一種多徑流式傳輸系統(tǒng)的框圖。
[0024]圖13示出了可以由實(shí)現(xiàn)多徑可靠性控制協(xié)議的多徑流式傳輸系統(tǒng)使用的一組可能的數(shù)據(jù)格式。
[0025]圖14是一種多徑流式傳輸發(fā)送方的框圖。
[0026]圖15是一種多徑流式傳輸接收方的框圖。
[0027]圖16描繪了在多徑的基于FEC的可靠性傳輸控制方法的操作期間，源塊的不同分類的快照。
【具體實(shí)施方式】
[0028]很多研究人員的研究已經(jīng)表明，當(dāng)使用TCP時(shí)，數(shù)據(jù)傳送的吞吐量(以分組每秒為單位)與以下二者的乘積成反比:RTT(以秒為單位)和端到端連接上的丟失率的平方根。例如，美國和歐洲之間的典型端到端地面連接具有200毫秒的RTT和平均2%的分組丟失率，并且IP分組的大小通常大約為10千比特。在這些狀況下，TCP連接的吞吐量是大約每秒最多300-400千比特(kbps)，而無論端到端之間有多大的可用帶寬。這種情形在衛(wèi)星鏈路上更加嚴(yán)重，其中在衛(wèi)星鏈路上，除了具有高RTT之外，還由于各種大氣效應(yīng)而丟失信息。
[0029]作為另一例子，已知移動(dòng)網(wǎng)絡(luò)(3G或LTE網(wǎng)絡(luò))中的移動(dòng)設(shè)備經(jīng)歷較大的RTT、RTT的動(dòng)態(tài)波動(dòng)、以及可用帶寬的動(dòng)態(tài)波動(dòng)。移動(dòng)設(shè)備可能因?yàn)楦鞣N各樣的原因而具有這些體驗(yàn)，所述原因包括:移動(dòng)設(shè)備在小區(qū)內(nèi)或者移動(dòng)穿過小區(qū)邊界的位置改變，這可能造成覆蓋的波動(dòng)；由于其它移動(dòng)設(shè)備靠近或者離開向該移動(dòng)設(shè)備提供覆蓋的小區(qū)而造成的網(wǎng)絡(luò)負(fù)載的變化；以及各種其它原因。TCP在這些類型的狀況之下具有較差性能的主要原因在于:TCP使用的速率控制協(xié)議在這些狀況下不能很好地工作，例如，即使可用帶寬在較短的時(shí)間段內(nèi)較高，TCP協(xié)議也不能夠足夠快速地反應(yīng)來增加其傳輸速率以在該可用帶寬再次降低之前充分利用該較高的可用帶寬。
[0030]由于TCP使用的可靠性控制協(xié)議和速率控制協(xié)議是不可分離的，因此這意味著整個(gè)TCP協(xié)議不適用于這些狀況。一種嘗試克服TCP的這些限制的方式是在單獨(dú)的路徑上使用多個(gè)TCP連接，以進(jìn)一步增加聚合的端到端吞吐量。此外，不同的應(yīng)用對于傳輸?shù)囊笠膊煌?，然而TCP相當(dāng)普遍地用于所有網(wǎng)絡(luò)狀況下的各種應(yīng)用，因而在很多情形下導(dǎo)致較差的性能。
[0031]例如，對于實(shí)時(shí)視頻流式傳輸應(yīng)用而言，視頻可以在移動(dòng)設(shè)備上的視野中生成，并可能使用通過WiFi系留或者連接到該生成移動(dòng)設(shè)備的多個(gè)移動(dòng)設(shè)備，在多個(gè)TCP連接上，可能在不同的3G或4G/LTE連接上，流式傳輸?shù)綄⒅貥?gòu)該原始視頻流的接收設(shè)備。然而，由于可用帶寬的波動(dòng)和RTT的波動(dòng)，這些多個(gè)TCP連接可能仍不能充分地利用可用帶寬。對于這樣的流式傳輸應(yīng)用而言，實(shí)時(shí)流式傳輸應(yīng)用對端到端延遲的要求可能是非常嚴(yán)格的，因而存在如下進(jìn)一步的復(fù)雜度和要求:該流包括一系列的數(shù)據(jù)塊，以及需要接收在不同的TCP連接上發(fā)送的針對各個(gè)數(shù)據(jù)塊的足夠的編碼單元，以使得在接收設(shè)備處得以對該流的該數(shù)據(jù)塊進(jìn)行重構(gòu)，以及通常在接收設(shè)備處以具有以下兩個(gè)時(shí)間點(diǎn)之間的最小可能延遲來順序地消費(fèi)或回放這些數(shù)據(jù)塊:當(dāng)在發(fā)送方處使各個(gè)數(shù)據(jù)塊(部分或全部)可用時(shí)以及當(dāng)在接收設(shè)備處重構(gòu)該數(shù)據(jù)塊并使其可用于回放或消費(fèi)時(shí)。這些要求可能使基于TCP的解決方案的能力受到最慢TCP連接的約束，故基于TCP的總解決方案可能是非常遜色的。
[0032]本公開內(nèi)容包括改進(jìn)的可靠性控制協(xié)議和速率控制協(xié)議的描述，這兩種協(xié)議可以獨(dú)立地使用，并且相同的可靠性控制協(xié)議可以與各種不同的速率控制協(xié)議一起使用，使得所選擇的實(shí)際速率控制協(xié)議可以是基于應(yīng)用要求和該應(yīng)用所運(yùn)行的網(wǎng)絡(luò)狀況。MicahAdler、Yair Bartal、John Byers、Michael Luby、Danny Raz 于 1997 年 6 月在第五屆以色列計(jì)算和系統(tǒng)理論研討會(huì)(the Fifth Israeli Symposium on Theory of Computingand Systems)的議程中發(fā)表的論文“A Modular Analysis of Network Transmiss1nProtocols”(下文稱為“Adler”，并以引用方式并入本文)介紹了用于構(gòu)建傳輸協(xié)議的模塊化方法，其主張將可靠傳輸協(xié)議劃分成獨(dú)立的可靠性控制協(xié)議和速率控制協(xié)議。
[0033]對于任何可靠性控制協(xié)議而言，其性能的兩項(xiàng)主要測量值是要求多少緩沖以及其“有效吞吐量”。在發(fā)送方和接收方二者處的可靠性控制協(xié)議中引入了緩沖。例如，發(fā)送方處的緩沖發(fā)生于:當(dāng)數(shù)據(jù)被首次發(fā)送之后就對該數(shù)據(jù)進(jìn)行緩沖，直到發(fā)送方獲得了在接收方處已經(jīng)接收到該數(shù)據(jù)的確認(rèn)為止。接收方處的緩沖由于類似的原因而發(fā)生。對緩沖感興趣的原因有兩點(diǎn):(1)其直接影響發(fā)送方和接收方可靠性控制協(xié)議使用多少存儲器；(2)其直接影響發(fā)送方和接收方可靠性控制協(xié)議引入多大延時(shí)。有效吞吐量被定義為:將要傳送的數(shù)據(jù)的大小除以在該傳送期間在接收方端系統(tǒng)處接收到的已發(fā)送數(shù)據(jù)的量后得到的值。例如，如果在分組中發(fā)送的用于傳送原始數(shù)據(jù)的數(shù)據(jù)的量是該原始數(shù)據(jù)的大小，則有效吞吐量=1.0，并且如果沒有發(fā)送冗余數(shù)據(jù)，則可以實(shí)現(xiàn)有效吞吐量=1.0。
[0034]Adler概述了在很大程度上獨(dú)立于所使用的速率控制協(xié)議的可靠性控制協(xié)議，其在下文被稱為“無編碼(no-code)可靠性控制協(xié)議”。無編碼可靠性控制協(xié)議在某些方面類似于TCP中嵌入的可靠性控制協(xié)議，在該意義上，原始數(shù)據(jù)被劃分成一些塊，并且每個(gè)塊在分組的有效載荷中發(fā)送，然后需要接收各個(gè)塊的精確副本以確保可靠傳送。使用無編碼可靠性控制協(xié)議的問題在于:盡管有效吞吐量是最優(yōu)的(基本上等于一)，但當(dāng)存在分組丟失時(shí)，無編碼可靠性控制協(xié)議引入的緩沖可能非常大。Adler證明了無編碼可靠性控制協(xié)議處于不使用編碼來傳輸數(shù)據(jù)的可靠性控制協(xié)議之中的最佳常數(shù)因子內(nèi)，在該意義上，該協(xié)議具有最佳的有效吞吐量，并且依據(jù)使發(fā)送方和接收方處所需要緩沖的量最小化而言，可證明是處于最佳常數(shù)因子內(nèi)的。
[0035]在可靠性控制協(xié)議中已經(jīng)使用的一種技術(shù)是前向糾錯(cuò)(FEC)編碼，例如里德-所羅門編碼(Reed-Solomon code)或Tornado編碼或者鏈?zhǔn)椒磻?yīng)編碼(其是信息附加編碼)。使用FEC編碼，將原始數(shù)據(jù)劃分成比分組的有效載荷更大的塊，然后根據(jù)這些塊來生成編碼單元，并在分組中發(fā)送這些編碼單元。與不使用編碼的可靠性控制協(xié)議相比，這種方法的一項(xiàng)基本優(yōu)點(diǎn)在于:反饋可能是更簡單的和更不頻繁的，即，對于每個(gè)塊而言，接收方僅僅只需要向發(fā)送方指示接收到的編碼單元的數(shù)量，而不用確切地列出接收到哪些編碼單元。此外，與原始數(shù)據(jù)塊的長度相比，聚合生成和發(fā)送更多的編碼單元的能力，在設(shè)計(jì)可靠性控制協(xié)議時(shí)是一種強(qiáng)大的工具。
[0036]諸如里德-所羅門編碼或Tornado編碼之類的糾刪編碼針對固定長度的塊生成固定數(shù)量的編碼單元。例如，對于包括B個(gè)輸入單元的塊而言，可以生成N個(gè)編碼單元。這N個(gè)編碼單元可以包括B個(gè)原始輸入單元和N-B個(gè)冗余單元。如果存儲裝置準(zhǔn)許，則發(fā)送方可以只對針對各個(gè)塊的編碼單元的集合進(jìn)行一次計(jì)算，并使用輪播協(xié)議(carousel protocol)來發(fā)送這些編碼單元。
[0037]使用一些FEC編碼的一個(gè)問題在于:它們要求過多的計(jì)算能力或存儲器來進(jìn)行操作。另一問題在于:必須在編碼過程之前確定需要的編碼單元的數(shù)量。如果分組的丟失率估計(jì)過高的話，這可能導(dǎo)致低效率，而如果分組的丟失率估計(jì)過低的話，則可能導(dǎo)致失敗。
[0038]對于傳統(tǒng)FEC編碼而言，可以生成的可能的編碼單元的數(shù)量與一個(gè)塊被劃分成的輸入單元的數(shù)量具有相同的數(shù)量級。通常，但不完全是，這些編碼單元中的大部分或者全部在發(fā)送步驟之前的預(yù)處理步驟中被生成。這些編碼單元具有如下屬性:可以根據(jù)這些編碼單元的任何子集來重新生成輸入單元，所述編碼單元在長度上等于原始塊或者比原始塊稍微更長。
[0039]美國專利N0.6，307，487 (下文稱為“Luby I ”，并以引用方式并入本文)中描述的鏈?zhǔn)椒磻?yīng)解碼可以提供一種解決上述問題的前向糾錯(cuò)的形式。對于鏈?zhǔn)椒磻?yīng)編碼而言，可以生成的可能的編碼單元的池在數(shù)量級上大于輸入單元的數(shù)量，并且可以非常迅速地生成根據(jù)該可能池的隨機(jī)或者偽隨機(jī)選擇的編碼單元。對于鏈?zhǔn)椒磻?yīng)編碼而言，可以與發(fā)送步驟同時(shí)地，在“按需的”基礎(chǔ)上飛速生成編碼單元。鏈?zhǔn)椒磻?yīng)編碼允許根據(jù)隨機(jī)或偽隨機(jī)生成的編碼單元集合的子集來重新生成內(nèi)容的全部輸入單元，所述編碼單元在長度上比原始內(nèi)容稍微更長。
[0040]諸如美國專利N0.6，320，520、6，373，406、6，614，366、6，411，223、6，486，803 和美國專利公開N0.2003/0058958(下文稱為“Shokrollahi I”)之類的其它文檔描述了各種鏈?zhǔn)椒磻?yīng)編碼方案，并以引用方式并入本文。
[0041]使用鏈?zhǔn)椒磻?yīng)編碼的發(fā)送方可以針對正在發(fā)送的每個(gè)塊，持續(xù)地生成編碼單元。可以通過用戶數(shù)據(jù)報(bào)協(xié)議(UDP)單播或者UDP多播(如適用)將這些編碼單元發(fā)送給接受方。假定每個(gè)接受方都裝備有解碼單元，該解碼單元對分組中接收的合適數(shù)量的編碼單元進(jìn)行解碼以獲得原始塊。
[0042]現(xiàn)有的簡單的基于FEC的可靠性控制協(xié)議(下文稱為“TF可靠性控制協(xié)議”)發(fā)送針對給定數(shù)據(jù)塊的編碼單元，直到從接收方接收到已經(jīng)接收了足夠的編碼單元來恢復(fù)該塊的確認(rèn)為止，然后發(fā)送方移動(dòng)到下一個(gè)塊。
[0043]假設(shè)RTT是從當(dāng)發(fā)送方發(fā)送分組時(shí)開始，到發(fā)送方從接收方接收到該分組已經(jīng)到達(dá)的確認(rèn)為止的秒的數(shù)量，以及假設(shè)R是發(fā)送方的當(dāng)前發(fā)送速率(以分組/秒為單位)，以及假設(shè)B是塊的大小(以分組為單位)。使用TF可靠性控制協(xié)議，包含為了恢復(fù)一個(gè)塊而需要的最后分組之后發(fā)送的針對該塊的編碼單元的無用分組的數(shù)量是N = R*RTT。因而，f= N/(B+N)部分的發(fā)送的分組被浪費(fèi)了，因而有效吞吐量至多是l_f。例如，如果R= 1，000分組/秒，RTT = 1秒，并且B = 3，000個(gè)分組，則f = 0.25，即，浪費(fèi)了 25%的所接收的分組。因此，在這個(gè)例子中，有效吞吐量是不足的0.75 (與1.0的最大可能有效吞吐量相比)。
[0044]在這個(gè)例子中，還應(yīng)當(dāng)注意的是，塊的大小B連同速率R —起意味著簡單的基于FEC的可靠性控制協(xié)議所引入的延時(shí)至少是4秒(發(fā)送每個(gè)塊總共需4秒鐘)，并且要求緩沖至少一個(gè)塊，即3，000個(gè)數(shù)據(jù)分組。此外，為了增加有效吞吐量，要求增加緩沖，或者相反地，為了減少緩沖，則要求減少有效吞吐量。
[0045]以Luby等人名義申請的美國專利N0.7，447，235 (下文稱為“Luby II”)描述了改進(jìn)的基于FEC的可靠性協(xié)議。然而，用于在多個(gè)路徑上進(jìn)行流式傳輸?shù)母倪M(jìn)的可靠性控制協(xié)議是期望的。此外，提供可以與改進(jìn)的可靠性控制協(xié)議進(jìn)行組合的相應(yīng)的速率控制協(xié)議，以獲得使可靠性和有效吞吐量最大化，并使端到端延時(shí)最小化的適合于在多個(gè)路徑上進(jìn)行流式傳輸?shù)膫鬏攨f(xié)議是期望的。
[0046]在根據(jù)本公開內(nèi)容的例子中，可以使用用于多徑傳輸?shù)慕豢検娇煽啃钥刂茀f(xié)議來提供相對于TCP、TF可靠性控制協(xié)議和無編碼可靠性控制協(xié)議、以及Luby II中描述的基于FEC的可靠性協(xié)議的改進(jìn)。此外，介紹了可以與改進(jìn)的可靠性控制協(xié)議進(jìn)行組合的改進(jìn)的速率控制協(xié)議和生成速率協(xié)議，以提供使可靠性和有效吞吐量最大化，并使端到端延時(shí)最小化的適合于在多個(gè)路徑上進(jìn)行流式傳輸?shù)膫鬏攨f(xié)議。
[0047]在使用可靠性控制協(xié)議的情況下，數(shù)據(jù)塊被發(fā)送為從發(fā)送方到接收方的一系列的編碼單元，并且接收方對這些編碼單元或者塊的恢復(fù)進(jìn)行確認(rèn)，從而使發(fā)送方得以確定接收方是否接收到該數(shù)據(jù)，并當(dāng)沒有接收到時(shí)，對該數(shù)據(jù)進(jìn)行重傳，或者發(fā)送可用于恢復(fù)所接收的數(shù)據(jù)的其它數(shù)據(jù)。一些交織式可靠性控制協(xié)議的一種屬性在于以交織的方式來發(fā)送針對不同塊的編碼單元。交織式可靠性控制協(xié)議具有如下屬性:當(dāng)與實(shí)質(zhì)上任何速率控制協(xié)議進(jìn)行組合時(shí)，它們提供高效的可靠數(shù)據(jù)傳輸，其使端系統(tǒng)處的緩沖(和隨之發(fā)生的延時(shí))最小化，并使該傳輸?shù)挠行掏铝孔畲蠡?br>[0048]根據(jù)本公開內(nèi)容的技術(shù)，交織式可靠性控制協(xié)議可以與合適的速率控制協(xié)議一起使用，以確保數(shù)據(jù)的可靠傳送，同時(shí)維持高吞吐量，即使當(dāng)存在高丟失率時(shí)和/或當(dāng)存在較大的RTT時(shí)。例如，速率控制協(xié)議可以與按照固定的速率進(jìn)行發(fā)送一樣簡單，并且交織式可靠性控制協(xié)議將保證數(shù)據(jù)按照等于固定速率乘以成功到達(dá)的分組的比例后的速率進(jìn)行傳送，同時(shí)使該傳送期間的緩沖和延時(shí)最小化。
[0049]作為由此處介紹的交織式可靠性控制協(xié)議所提供的量化性改進(jìn)的例子，假使速率控制協(xié)議按照每秒R個(gè)分組的固定速率來發(fā)送分組，發(fā)送方和接收方之間的往返時(shí)間是RTT秒，因而N = R*RTT是在途的未被確認(rèn)分組的數(shù)量。對于無編碼可靠性控制協(xié)議而言，發(fā)送方處的總緩沖區(qū)大小B至少是N*ln(N)，以及有效吞吐量近似是1.0，并且在所需要的緩沖的量和有效吞吐量之間不存在可能的其它權(quán)衡點(diǎn)。此處，In (X)被定義為X的自然對數(shù)。在使用TF可靠性控制協(xié)議的情況下，發(fā)送方處的總緩沖區(qū)大小至少是B，并且有效吞吐量近似是B/(B+N)，其中B是選擇的塊大小