Fountain Code 應用於平行傳輸的技術剖析
吳東澤 楊哲男
國家高速網路與計算中心
woodjason@nchc.org.tw
yangcn@nchc.org.tw
摘要
為了節能而降低傳輸功率會導致丟包率增加，補
償的做法是利用 FEC Code 將失去的封包復原，以
達到既省電又具效能的傳輸。於是 FEC-TCP 可以
降低能源功率消耗的研究日益受重視，許多研究建
議將能源消耗、FEC、ARQ 等三個參數一併考量計
算。然而一般的 FEC 都是基於固定編碼率的 Block
Code，Block Code 仍必須事先量測通道的丟包率，
並且在變動丟包率的情況下表現不佳。 Fountain
Code 則不需要考慮這些，發送端將 K 份資料編碼
如泉水般不斷流往接收端，接收端如裝水般收滿 N
份(略大於 K)即可解回原始資料，其可以抵禦變動
丟包率的特性使之被稱為 rate-less code，LT Code
是第一個實現此目標的 FEC Code。另一方面，SCTP
是目前最先進的網際網路傳輸協定，利用多路徑靈
活地增進了傳輸效能。本篇論文選定 LT Code 為主
題，敘述了 LT Code 的階數與 pdf 分佈，分析現行
網路傳輸機制並敘述如何利用 Fountain Code 階數
來達到差異化保護，指出在實際應用上的方法以及
與 SCTP 相關的多路徑特性，達到平行傳輸，及避
免過度的頻寬浪費，以期在降低能源消耗的同時確
保傳輸效能，並在文末探討未來可繼續延伸的研究
方向。
關鍵詞：
Fountain code，LT code，FEC-TCP，SCTP，傳輸效
能，節能科技
1. 前言
SCTP(Stream Control Transmission Protocol) [18]
是目前最先進的網際網路傳輸協定，不僅能結合各
種 TCP 的改良以增進效能(SACK、NewReno、Early
Retransmit)[2]，還能利用不同的技術[10]偵測多路
徑的頻寬以選擇合適的路徑，更靈活地增進了傳輸
效能。
在 改 善 TCP 效 能 的 另 一 方 面 ， 錯 誤 更 正 碼
Forward Error Correction Code(FEC 或稱 Erasure
Correction Code，因為網路封包只要驗證碼不過，
該封包即被丟棄，網路通道常歸類為 Binary Erasure
Channel，BEC)一開始是基於網路第二層 link layer
的觀點[1,4]，然而端到端(end to end)的 FEC 有著最
顯著的便利性：即使用封包為編碼單位而不影響所
有路徑上路由器的架構[3,9,13]。此外無論是在綠能
科技、無線傳輸節能方面，降低能源的使用率近來
也日益受到重視[5,8]，適當的 FEC 可以降低能源消
耗，於是許多研究建議將能源功率消耗、FEC、
ARQ(Automatic Repeat-reQuest)等三個參數一併考
量計算。
在降低功率消耗之後丟包率也增加了，適當的
FEC 雖然可以減少 ARQ 的比率，然而前述研究內
容所探討的 FEC 都是基於固定編碼率的 Block code，
Block code 仍必須事先量測通道的丟包率，進而增
加相對應比例的冗餘碼，但是一旦丟包率超過修正
負荷則失去修復能力，於是被稱為 fix-rate code，而
無法修復的部分還是必須用上 ARQ 來通知重送。
Fountain Code 可以描述為：發送端將 K 份資料
編碼後，如泉水般不斷流往接收端，無論接收過程
的漏水(丟包)程度，接收端如裝水般收滿 N 份(略大
於 K)即可解回原始資料，其可以抵禦變動丟包率的
特性使之被稱為 rate-less code，此外 Fountain Code
的 random 特性使之適合用於平行傳輸，原因在 2.2
節以後會詳加解釋。
Luby Transform Code(LT Code)[12]是第一個實現
此目標的 FEC Code，於是本篇論文選定 LT Code
為討論主題，敘述了 LT Code 的階數(degree) 的機
率分佈 pdf(probability distribution function)，分析現
行網路的傳輸機制與 Luby Transform 參數之間的關
聯性，指出 Fountain Code 在實際應用上與 SCTP 相
關的多路徑特性，在平行傳輸的同時得以容忍變動
的丟包率，以期在降低傳輸功率下符合綠色節能與
提升性能的雙重目標，並在文末探討未來可繼續延
伸的研究方向。
2. Fountain Code 在網路傳輸的適應性
Fountain Code 其理想是不需要考慮丟包行為，如
同從一個供水系統接水一樣，每滴水的地位相等便
不需要去關注掉了哪些封包，僅要確定收到足夠的
封包數即可將編碼還原。
2.1 ACKnowlegement Packets
有效率的傳輸其意義是在容許的頻寬內盡量將
資料送往對方；Ordering TCP 的做法是利用 end to
end 之間的 ACK 行為來確保在不造成丟包的情況 封包之後會更有效率。
下盡量將回傳的數量盡量減少；FEC-TCP 則是增加
一小比例的冗餘碼，無法修復時才通知重傳， 2.2 The Random Nature of Fountain Code
Ordering TCP 與 FEC-TCP 的效能評比如圖 1 所示。
基於 Fountain Code 的 Fountain base protocol(FBP) 當發送端的原始資料經過 Fountain 編碼之後，便
並不專注於目前要傳送”哪個”原始資料，而是將這 沒有”次序”的區分了， FBP 讓封包如同泉水的每滴
些資料一視同仁地隨機選取特定數量的資料做編 水滴一樣地位平行，這樣一來的好處就是可以利用
碼，只要隨機選取的資料數量是符合特定 pdf 分佈 接收端的各種媒介頻寬來接收資料，而無須考慮如
的情況，接收端能在冗餘封包極少的情況下將編碼 何整合收到資料的次序，然而現今的 SCTP 仍是基
還原。 於 Ordering TCP 下的實作方式。
Ordering TCP 的壅塞控制在 RTT 極長、JITTER 最顯著的應用就是平行傳輸，如同 SCTP 般的建
極大的情況下效率會明顯降低，然而 Fountain Code 立多條連線，然而卻不需像 Ordering TCP 必須審慎
不會受到這些干擾的影響，但是這並不代表 ACK 考量接收封包的次序、將收到資料重整、超過等待
機制不需要深入研究。ACK 同時也扮演著量測通訊 時間再重新傳送。不像 SCTP 的傳輸速度受限於主
通道的狀況，回報 RTT、JITTER、可用頻寬、丟包 要路徑的連線瓶頸，只要是 FBP 所有備用連線的頻
率等數據，對於一個可用的通訊方法來說，判斷路 寬也可以同時被利用。
徑上的可用頻寬由其重要，SCTP 可說是有著多路 另一個應用也同樣有著異曲同工之妙，[15]解釋
徑選徑功能的 Ordering TCP，在 SCTP 上常用來判 是在於異地(甚至多地)的資料備原機制。我們將資
斷路徑瓶頸的 packet pair method 可以用圖 2 表示。 料經過 Fountain 編碼再儲存到異地的伺服器上，日
後需要讀取資料的時候所有備份伺服器的頻寬都
可以同時被接收端利用，以達到快速讀取或是快速
復原資料的目的。

2.3 Nash Equilibrium

文獻[11]利用著名的 Game Theory 對於 TCP 與

FBP 兩者做了有趣的分析。Tragedy of Commons 描
述的是當一項資源被大家所共同持有，惡意使用者
越 多 的 下 場 是 資 源 被 大 家 消 耗 殆 盡 ， Nash
Equilibrium 則描述若大家審慎使用這些資源便不會
導致災難的發生而可以達到一個對彼此都最佳的
狀況。

圖1 FEC 讓 TCP 性能得到顯著提升[13]

圖3 FBP 與 TCP 的性能比較[11]

網路路由器的頻寬對於所有使用者來說都是共
圖 2 判斷路徑瓶頸頻寬[10] 同持有的資源，TCP 各種控制的原意就是要避免
Tragedy of Commons 的發生，然而[11]的實驗顯示
Fountain Code 其原意就是不需要任何 ACK 封包 FBP 不僅可以導致十分穩定的 Nash Equilibrium，還
的協助仍可完成傳輸工作，然而加入適當的 ACK 比 TCP 較難招致 Tragedy of Commons 的發生，如
FBP 在圖 3 中維持一個穩定的平台，直到惡意使用 ρ(i)是 Luby Transform 的關鍵，如圖 4 的 rho，其定
者超過 11 效率才開始下降，TCP 方面惡意使用者 義如下：
在 11 的時候，效率已經下降幾近為零了。而且使用
ρ
者在可以選擇 protocol 的情況下會偏好 FBP，因為
FBP 的效率比 TCP 還高得多。 ρ

3. Luby Transform Code

FEC 的精髓就是 XOR 運算，以下用一個簡單的
例子解釋：
a=X
b=Y
c=X+Y+Z
d=Z
在上述的例子當中大寫 X、Y、Z 是原始資料，
小寫 a、b、c、d、…為編碼封包，符號+代表對原
始資料做 XOR 運算，比如說 c 代表對 X、Y、Z 做
XOR 運算之後的值，X、Y、Z 在這個例子都各出
現兩次。於是這樣的編碼規則將可以應付下列狀
況：
當 a、b、c 任消去一個的時候，接收端只要繼續
接收 d 就可以解回 X、Y、Z，當然這個例子可以繼
續掉封包，而後延伸出 e、f、g…，並期待能早日
收到接收端傳來已解完的 ACK。
我們可以把上面這個例子用數學寫下來，隨機選 圖4 ρ(rho), τ(tau)的 pdf, K=10000, c=0.2, δ=0.05
取資料，並保持一定機率將所有的資料 XOR 運算 (橫軸為編碼階數，縱軸為機率)[15]
之後當作冗餘碼。a、b、d 稱為階數 1(degree one)，
c 則稱為階數 3(degree three)，在 3 個樣本的情況下，
階數 1 的機率約 2/3，階數 3 的機率約 1/3，於是可
以推廣到 k 個原始資料，這樣的編碼機率公式如：
階數 的機率是

階數 的機率是

可想而知這樣的編碼方式效率不夠好，為了要讓接
收端能有效將編碼解回，Luby 發展了複雜的機率分
佈。
除了 LT Code 之外，仍然有許多新穎而卓越的
Fountain Code 正在被研究當中，由於 LT code 是第
一個達到 Fountain Code 的標準，同時也是最知名而
具代表性的編碼方式，本章節介紹 LT Code 的階數
分佈 pdf。

3.1 Ideal Soliton Distribution

Luby[12]為了快速解碼證明了一個最理想的編
碼機率分佈，稱為 Ideal Soliton Distribution，其方
法描述如下：
K 個原始資料 s1,s2,s3…sK 經過以下步驟編成已編
碼封包 tn。
1. 隨機由階數分佈 ρ(i)中選擇階數 i。
2. 隨機由 K 個原始資料中選擇 i 個資料，將之作
XOR 運算之後，即為已編碼封包 tn。
圖 5 需要 N 封包來解回檔案的 Host 比率
(橫軸為 N，縱軸為 Host 比率，K=10000)[15]
(a) c=0.01, δ=0.5
(b) c=0.03, δ=0.5
(c) c=0.05, δ=0.5
這是[12]考慮到理想的狀況下，僅需要一個階數
為一的封包，並且在解碼的過程中都恰好有一個可
立即被處理的 t。然而錯誤更正碼即是要容忍變動
比例的丟包，假使過程中發生沒有階數為一的封包 STEP 1
可處理時，解碼即被中斷。於是 Luby 提出微調過 決定最高階數 d
的 Robust Soliton Distribution 實作 Fountain Code， STEP 2
增加一些”漣漪”讓解碼過程不致中斷。
STEP 3
3.2 Robust Soliton Distribution for ( i = 1 ; n > f(i) ; i++ )
n -= f(i);
STEP 4
Robust Soliton Distribution[12]，μ，其主要用來製
i 即是我們欲取的階數，重複 2、3 步驟
造漣漪的函式 τ 中新增了兩個參數 c 與 δ 供使用者
即可依 pdf f(x)產生欲編碼的階數。
視情況調整，該函式如圖 4 的 tau，定義如下：

0.5
0.45
τ 0.4
0.35
0.3
0.25
0.2
其中 為預期階數為 1 的封包數， 0.15
δ
階數為 1 即為原始資料的複本。而函式 τ 加上 Ideal 0.1
Soliton Distribution 之後，再標準化到總和為一，即 0.05
0
為 Robust Soliton Distribution，μ：
1 2 3 4 5 6 7 8 9 10
階數pdf f(i)

光是經由調整參數 c 與 δ，在 K 的數量到了 10000 圖 6a 階數分佈的 pdf

個封包的時後，已經可以將冗餘控制在極理想的 5%
以下，而這些實驗都尚未增設任何 ACK 頻寬，發
送端是設定在”盲目發送”，而沒有任何 ACK 供參 階數cdf g(i)
考。如圖 5 所示，實驗顯示以設定(b)為佳。
1
0.9
4. Fountain Code 的階數與參數分析 0.8
0.7
隨機與階數分佈是 Fountain Code 的菁華，4.1 敘 0.6
述了如何依照 pdf 選取編碼封包的階數，4.2 介紹 0.5
Robust Soliton Distribution 的階數調整。另一方面由 0.4
於無法預期封包丟包的特性而一視同仁讓每滴水 0.3
的地位相等，原始資料選取階數採均勻分佈。然而 0.2
0.1
不均勻地選取階數會帶來許多有趣的好處，以下兩
0
節簡單介紹其中幾項特性。4.3 介紹差異化服務，
1 2
以及在 4.4 敘述 ACK 對於 FBP 的益處。 3 4
5 6 7 8 9
10
4.1 隨機取階數的實作方式

Fountain Code 必須確定接收端解完所有封包之

後才停止傳送，這表示 Fountain Code 的編碼端必須 圖 6b 對應 6a 的 cdf
依照 pdf 製造無止盡的亂數來決定哪些封包該被編
碼，直到收到接收端傳來”已完成”的 ACK。依照 說明：
pdf 產生無盡亂數這樣的描述或許容易讓人混淆， 每個 pdf 的累進就是其對應的 cdf(cumulative
不過值得一提的是這裡討論到的亂數單純在於既 density function)，圖 6a 階數 pdf f(x)的 cdf 令為 g
定的正整數上，無盡而非無窮詳細。為了精確解釋， 如圖 6b。此例 pdf 最高階數是 10，0 至 g(10)即是
以下簡單敘述依 pdf f(x)產生無盡亂數以決定編碼 步驟 2 的亂數範圍，而機率累進如 cdf 縱軸，機率
階數的方法與其說明。 越高的階數投影在縱軸的長度越長而反之亦然，所
以每個階數機率都符合 pdf 分佈。而步驟 3 則是要
方法： 判斷該亂數位於哪一個階數區間。
4.2 以參數調整階數分佈 Z 在這個例子都各出現兩次。
這個例子很像是方程式求解，我們會很想用高斯
階數的分佈是 Fountain Code 的核心，對於 LT 消去法把解算出來。然而不幸的是 a、b、c 其中有
Code 來說，Luby 保留了參數 c 與 δ 的詮釋空間， 一個值不見了，這時候我們會發現，a、b、c 無論
其原文[12]是”以適合的 c 與 δ 代入”，本節討論參 去掉哪一個，永遠都可以解出 X 這個值。於是我們
數與階數分佈。 可以理解階數越低的資料越容易被解回，相對來說
文獻[7]利用 Robust Soliton Distribution 給了明確 階數越高的資料則相反。
的參數 c 區間分析：
4.4 ACK 對於 Fountain based protocol 的益處

適量的 ACK 除了如 2.1 節所述可以偵測回報

文獻[6]針對短編碼長度的 LT Code 做了參數分 RTT、JITTER、可用頻寬、丟包率等數據讓發送端
析，其中的表格 c 與 δ 如表 1： 更了解接收端的狀況，適當的 ACK 搭配了 Fountain
Code 本身差異化服務的性質，發送端能夠區分尚未
表1 c 與 δ 的影響[6] 解回的原始資料，將未解回的部分放在低階數的編
Characteristic Increase c Increase δ 碼區，進而減少傳送全都是已解回資料的比率，因
Average degree Decreases Increases 為這些資訊對於接收端是完全無幫助的。
Degree Increases 在平行傳輸方面，如同 SCTP 般的建立多條連線
Increases
one probability (almost constant) 之後，即可開始傳送封包，接收端經由 packet pair
First peak Decreases Increases method 即可以回傳適用頻寬的 ACK，以免過度的
Increases
Second peak Decreases 封包遭到丟棄導致頻寬浪費。由於每個編碼封包的
(move left)
地位是平行的，可以同時利用多條路徑平行傳輸且
這裡承續前述研究繼續補充這些現象的說明。δ 不互相干擾，不像 SCTP 的傳輸會受限於主要路徑
被 Luby 本人解釋為編碼端無法復原所有封包的機 頻寬上限的瓶頸，連備用連線的頻寬也可以同時被
率，完成率則是(1－δ)，Luby 的 Robust Soliton 利用。在接收端解到一定數量之後則開始回傳”已解
Distribution[12]是為了彌補這點而設計的。我們可 開”的 ACK，向接收端更新已解開的資訊並同時更
新瓶頸頻寬上限。而在接收端完整將資料解回時，
以由式子觀查出， 是一個明顯的分界，這個高
nd
接收端傳送”已完成”的 ACK 通知發送端停止傳
階數分界的高機率(2 peak)是為了盡量確保所有的
送。
原始資料都要被納入編碼封包至少一次，類似其他
FEC 的 check node (如第三章簡單例子中的 node c)
5. Future Work
的用意。
當 時，τ=0。這表示越大的 R，會導致越多 本篇論文深入淺出的談論並敘述了 LT Code 的階
的 τ 變為 0，而參數 c 與 R 成正比。這隱含了 c 增 數與 pdf 分佈，分析現行網路傳輸機制並敘述如何
加會直接增加 τ(1)的機率，而由於越多的 τ 變為 0 利用 Fountain Code 階數來達到差異化保護，指出在
也降低了平均階數並且讓上述 Luby 所謂的分界階 實際應用上的方法與 SCTP 相關的多路徑特性，以
數降低(向左)，但會讓分界的機率值增加(向上)。 達到平行傳輸，及避免過度的頻寬浪費，這種傳輸
機制得以容忍變動的丟包率，以期在降低傳輸功率
4.3 差異化服務 下符合綠色節能與提升性能的雙重目標。
為了達到更高的目標，許多人正在研究更好的方
在實作上，假使要對原始資料作優先權的區分， 法。Maymounkov [16]在 2002 提出在編碼前加入
讓解碼端優先解回高優先權的資料也是很容易的 outer-encoding 的概念，Shokrollahi[17]在 2006 則利
事。一個很重要的事實是階數越低的資料會越先被 用此概念稱 pre-code 搭配 LT code 發展了 Raptor
解回來，這代表我們可以將越重要的資料放在越低 Code，於是內層的 LT code 尚無法解回來的部分，
階數的編碼區，以利解碼端優先將之解回，以下用 就靠外層的 Block code FEC 來解，這樣的機制能在
一個簡單的例子說明這樣的現象。 較少原始資料的情況下就發揮極佳的效能，Raptor
a=X Code 是當今已公開的最先進的標準，其已取得無線
b=Y+Z 通訊與衛星通訊等多項商用標準，並且專利權屬於
c=X+Y+Z 公司 Digital Fountain, Inc.所有。然而通常被拿來做
X 設為階數 1，Y 設為階數 2，Z 設為階數 3。同樣
pre-code 用的 LDPC[14](low density parity check
大寫代表原始資料，小寫代表編碼封包。X 階數 1
codes)本身的效能已經可以幾近 Shannon Limit 而顯
就是原始資料的複本如 a。Y 階數 2 表示還得另外
得十分有效率而卓越卻頗為艱深，但十分有挑戰性
選一個資料來做 XOR，均勻隨機的情況下很容易選
而值得研究。
到 Z，所以如 b。Z 階數 3 那沒話說就如 c，X、Y、
致謝
感謝所有國網中心的同事與我分享心得與知識；
特別感謝舍弟吳東霖熱心無私地提供具啟發性的
建議與有用的協助，他目前任職於 HTC 擔任通訊
工程師。我由衷希望這篇文章能足以躋身初接觸
Channel Code 人士的墊腳石行列。

參考文獻
[1] M. Allman, D. Glover, L. Sanchez, "Enhancing
TCP Over Satellite Channels using Standard
Mechanisms," BCP 28, RFC 2488, January 1999.
[2] M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton,
P. Hurtig, "Early Retransmit for TCP and SCTP,"
Internet Engineering Task Force, RFC 5827, April
2010.
[3] T. Anker, R. Cohen, D. Dolev, "Transport Layer
End-to-End Error Correcting," Technical Reports
submitted to the Leibniz Center, June 2004.
[4] C. Barakat, E. Altman, "Bandwidth tradeoff
between TCP and link-level FEC," Computer
Networks, vol. 39, no. 2, pp. 133-150, June 2002.
[5] D. Barman, I. Matta, E. Altman, and R. ElAzouzi,
"TCP Optimization through FEC, ARQ and
Transmission Power Tradeoffs," Proc. Conf.
Wired/Wireless Internet Comm., Feb. 2004.
[6] E. A. Bodine, M. K. Cheng, "Characterization of
Luby Transform Codes with Small Message Size
for Low-Latency Decoding," Proc. IEEE
International Conference on Communications, ICC
2008, Beijing, China, 19-23 May 2008.
[7] P. Cataldi, M. P. Shatarski, M. Grangetto, E. Magli,
"Implementation and Performance Evaluation of
LT and Raptor Codes for Multimedia
Applications," Proc. International Conference on
Intelligent Information Hiding and Multimedia,
2006.
[8] L. Galluccio, G. Morabito, S. Palazzo, M. Berioli,
G. Liva, "Optimizing TCP performance through
joint channel coding and power management in
power constrained satellite networks," Proc. of
IEEE Globecom 2008.
[9] C. Huitema, "The case for packet level FEC," Proc.
5th Workshop on Protocols for High-Speed
Networks, pp.109-120, October 1996.
[10] K. Lai, M. Baker, "Measuring Link Bandwidths
Using a Deterministic Model of Packet Delay,"
SIGCOMM 2000.
[11] L. López, A. Fernández, V. Cholvi, "A game
theoretic comparison of TCP and digital fountain
based protocols," Computer Networks, Volume 51,
Issue 12, August 2007.
[12] M. Luby, "Lt codes," in The 43rd Annual IEEE
Symposium on Foundations of Computer Science,
2002, pp. 271–282.
[13] H. Lundqvist and G. Karlsson, "TCP with
end-to-end FEC," International Zurich Seminar on
Communications, pp. 152 – 155, 2004.
[14] D. J. MacKay and R. M. Neal, “Near Shannon
limit performance of low density parity check
codes”,. Electronics Lett, vol. 33, no.6, pp.
457-458, Mar, 1997.
[15] D. J. MacKay, Information Theory, Inference,
and Learning Algorithms, Cambridge University
Press, 2003.
[16] P. Maymounkov, "Online codes," Research
Report TR2002-833, New York University, 2002.
[17] A. Shokrollahi, "Raptor Codes," IEEE
Transactions on Information Theory, vol. 52, pp.
2551-2567, 2006.
[18] R. Stewart, et al. "Stream Control Transmission
Protocol," Internet Engineering Task Force, RFC
2960, October 2000.