posted

0 Comments

作者: 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。下一篇我們與大家繼續進行討論。