作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與SD-WAN方案的介紹與推廣。

在這篇網誌內，我們要和大家展示Velocloud的FEC (Forward Error Collection) 網路流優化技術。基本上這個技術是針對語音及影像等UDP串流應用，在傳輸時如果碰到線路品質不佳，針對網路流封包本身進行的優化。但展示前，下圖可以給大家一個概念即Velocloud對於不同的應用網路流型態，是進行哪些優化機制：

在上圖內，大家可以看到針對被定義為Real-Time，且會是Multi-Path (受Tunnel保護) 形態的應用，除了在多線路上會採用Per-Packet Steering的方式去做線路的選徑與優化，同時也會對應用進行FEC與Jitter Buffer的優化 (Remediation)。當然，通常我們對於重要的語音或影像，比如說網路電話、影像會議等等，都會列在這一類。

在這邊的展示內，我們需要實驗組與對照組，因此與前幾篇不同，我們的網路環境配置會變成下面這樣：

從Branch-03-Linux (10.100.103.12)往右上角的 Hub-01-Linux (10.100.101.12) 間，是有建立Velocloud DMPO Tunnel（綠色虛線），受到保護與優化的線路。但在左下角的Branch-06，這個分點並沒有安裝VCE，而是透過基本的路由與其他分點或資料中心連接。因此由Branch-03-Linux 到左下角的Branch-06-Linux (10.100.106.12) 的網路流（紅色虛線），就是一般未受優化、未受保護的線路。

在這個實驗內，我們利用廣域網路模擬器，限制Branch-03這邊的MPLS線路頻寬上下行都是1 Mbps，然後將Packet Loss調到3%。大家可以看到，在VCO介面上，Branch 03 VCE的線路狀態有反應出這個狀況：

接下來我們先看正常環境內，沒有受到Velocloud保護的線路（前面的紅色線），在這樣的對照組網路狀況下會有什麼情形。實驗的方法如下：

 

  • 在Branch-03 / Branch-06的Linux機器上都安裝iperf3測試工具。
  • 將Branch-06-Linux作為iperf3的server端： # iperf3 -s -V。
  • 從Branch-03-Linux上啟動iperf3的client端發動測試，指令為 # iperf3 -c 10.100.106.12 -b 400k -t 300 -u 。這個指令要求從Branch-03-Linux發動UDP的測試網路流 (-u) 到目的地100.106.12，測試頻寬為400 kbps，然後持續300秒。

 

下面是測試結果的畫面：

上面畫面內，大家可以看到發動這個命令後，在Server端 (Branch-06-Linux-1) 總共於300秒內接收到1831個UDP的封包，平均頻寬為400 Kbps，裡面丟掉或錯誤了287個。也就是說，雖然在線路的Packet Loss是3%，但實際測試內，有造成接近1/6的封包出現問題。大家可以猜想一下如果你們實際的語音或影片傳送時，有1/6的封包出錯了，這個電話還打得下去嗎？

而在上面這個測試內，從VCO可以看到Branch-03的VCE線路狀態，MPLS線路上有平均為400K的網路流。

接著是真正的實驗組，也就是由Branch-03到Hub-01間，受到保護的Tunnel線路（前面的綠色虛線）。首先，在我們的Business Policy內，設定UDP的傳輸保護方式如下：

上面兩張圖內我們可以看到，對於UDP型態的封包，我們Business Policy的要求為

  • 必須要走Tunnel (Multi-Path)
  • 強制走MPLS線路 (Transport Group: Private Wired, Available)
  • 把這類封包定義為高優先權 (High) 的即時類應用 (Real-Time)。在這種交通型態內，等下我們要展示的FEC機制將會啟用。

做了這樣的設定後，我們在Branch-03-Linux內做與前面一模一樣的測試，只是目前的目標改成指向Hub-01-Linux (10.100.101.12)。結果如下：

一模一樣的頻寬與時間，大家可以看到在Server端 (Hub-01-Linux-1) 總共於300秒內接收到1830個UDP封包，平均頻寬為400 Kbps，但裡面丟掉或錯誤僅僅有14個，比率為0.77%。和前面同樣情況下有16%的封包錯誤，大幅優化了95%！當然在這個機制內不是百分之百的應用保護，可是在這個保護機制下，語音或影片的品質會好得多吧！

 

但是FEC的機制是怎麼做的呢？發生了什麼魔法讓封包丟失率大幅下降呢？其實很簡單，看下圖就一目瞭然了：

狀況是，雖然我們發送的是一個平均400 Kbps的串流，但MPLS上DMPO Tunnel實際的傳輸量卻是超過800 Kbps。為什麼？因為FEC的運作機制如下：

  • 對於被設定為High / Real-Time形態的網路流，如果偵測到線路掉包率過高，則啟用FEC機制
  • 此時在DMPO Tunnel的串流來源端，會直接把網路封包多複製一份，每個封包在線路內都丟兩個出去
  • 這時候即使線路品質不好會丟包，可能運氣也沒有這麼差，兩個封包都丟掉吧。此時在DMPO Tunnel的串流目的端，如果收到兩個一模一樣的封包，就移除其中一個傳出。如果同樣封包只有一個（表示一個遺失了），那就把這個留下來的繼續送出去。運氣很糟的狀況下還是有少數兩個都丟包了，那在應用端才會感受到有掉包的狀況

透過上述的機制，當Velocloud方案在實際客戶端用語音或影像串流驗證時，客戶能夠確實感受到重要的即時應用品質受到保障。當然這個機制不應該套用在所有的Application，因為頻寬會大幅上升，但對於高階長官或是業務重要的語音應用，有這樣的優化保護，網路管理者的壓力會減輕不少。

上面這邊我們在談的是UDP型態的語音與影像保護。那針對TCP型態的即時交易與傳檔呢？Velocloud有另一個機制NACK。下一篇我們與大家繼續進行討論。