傳輸時延問題研究和解析

王鵬 薛凌云

中國移動通信集團江蘇有限公司

0 引言

4G數據業務、VOLTE話音業務、互聯網視頻等業務對時延要求越來越高，傳輸系統對時延的影響也越來越凸顯，優化和提升傳輸系統時延是改善業務感知的重要手段。

1 時延產生的原因分析及解決方案

1.1 信號在光纖中的傳播時延

產生原因：

光信號在光纖中的傳播速度比在真空中慢，一般按照每毫秒200km計算。

解決方案：

對于因光纜傳輸距離過長引起的時延問題，需在網絡設計時，優化光纜路由組織，選取短路徑光纜進行信號傳輸。

1.2 網絡中間節點時產生的時延

1.2.1 處理時延

產生原因：

（1）路由器、交換機等網絡設備內部的處理時延一般為2 ～ 20us；

（2）小型設備時延低，報文進入設備后經過一次處理發送出去，如低端千兆交換機的典型時延為2～3us；

（3）大型設備時延高，報文需要經過入口板（Ingress card）、交換板（fabric crossbar）、出口板等幾次處理，處理流程更復雜，典型時延10～20us；

（4）SDH、DDN等時分復用傳輸設備的處理時延，一般為n×125us，不同設備取值不同，典型值是3×125us=375us。

解決方案：

硬件處理時長都很小，如果發現經過每個硬件時延過大，可以通過替換單板來解決。

1.2.2 發送時延

產生原因：

數據移出設備緩沖區所花費的時間，與線路帶寬和報文大小相關，例如：10GE線路上發送一個1538Byte的報文，1538×10/10E9 = 1.538E-6秒，也就是1.5us。如果換成GE線路，則為15us。

解決方案：

如果是由于發送端存在過大的時延，可以換成大帶寬的線路解決。

1.2.3 報文排隊時延

產生原因：

（1）由于線路繁忙，報文必須在網絡設備（路由器、交換機）中排隊等待；

（2）路由器的緩沖區大一些，最大排隊等待時間也比較大（200ms），以太網交換機小得多（＜1ms）；

（3）這個時間不是固定的，與網絡繁忙程度相關。網絡負載比較輕的時候，不需要排隊，無排隊時延。負載較重時，排隊則可能時延很大（幾十到幾百毫秒）；

（4）時分復用的SDH網絡設備無排隊等待時間。

解決方案：

對于帶寬不足，存在擁塞使得時延過大的情況，可以通過擴容帶寬，或者配置QOS使得對時延敏感的報文優先通過。

1.3 重傳時延和兩端處理時延

產生原因：

（1）重傳時延

當網絡因為負載太重出現丟包的時候，TCP協議發送端在超過重傳超時時限（RTO，retransmission timeout）還沒有收到接收端的ACK時，會重傳丟失的報文。多數操作系統的TCP/IP協議棧的實現里面RTO的最小值是200ms。

因此，一旦發生報文丟失，最少會引入200ms的時延。

（2）兩端處理時延

從網卡收到報文到發出中斷之間要一定的時間（典型值為100us）。最近比較新的網卡芯片會在收到報文之后延遲一段時間再產生中斷，以使一次中斷能夠處理更多報文，減少中斷保護和恢復現場產生的開銷。

從中斷服務程序、運行結束到應用程序收到報文并開始處理，任務切換需要一定時間（負載較重的服務器典型值為1ms左右）。

解決方案：

重傳引起的時延問題比較復雜，與協議、操作系統、下載軟件及配置等密切相關，本文以FTP為例進行說明，詳見下文。

2 FTP時延問題分析案例

2.1 問題現象

某網絡在LTE開局測試中，HQ1站點和B 站點的下載和上行速率都沒有達標。

圖1 FTP問題組網示意圖

2.2 問題分析

排查組網：兩個站點經過的公共路徑和設備都是華為OSN3500和 LAN Switch1。

帶寬配置：在OSN3500EGS4單板上綁定了一個VC4的帶寬，但上載速率最大只能到28M，下載速率只能到40M左右。排查OSN3500上沒有誤碼性能記錄，查看RMON流量統計，流量也沒有明顯超過帶寬，也沒有丟包的記錄。客戶要求下載帶寬要到100M。

FTP下載是基于TCP的運用，TCP的吞吐率主要受發送窗口大小、往返時延RTT、丟包率這三個因素影響。

Lambda（吞吐量）=n（未決請求的數量）/t（響應時間），在FTP Server端和PC Client端發送窗口設置為最大512KBytes的情況下，要達到峰值100Mbit/s的吞吐率，RTT時延最大不得超過40.5ms（=512×8bit/100Mbit/s）

測試網絡時延，從Lanswitch1 ping站點，時延都是5～6ms左右。從Lanswitch1 ping HQ1，時延也是在幾個ms。從Lanswitch2 ping的站點的時延也是在10ms左右。

但從Lanswitch2通過EPC（核心網的網元）ping Lanswitch1，時延達50ms～150ms，且不穩定。很明顯問題發生在EPC網元，排查出問題在于核心網的BUG，可通過更新版本解決。

2.3 解決方案及結論

除了丟包等因素，時延是影響FTP吞吐率的重要指標。在時延問題定位上可以通過分段ping定位，找出問題所在。

3 光纖中的傳播時延分析案例

3.1 問題現象

某客戶網絡，客戶反饋時延過大使得下游終端客戶業務受到影響。

3.2 問題分析

（1）梳理業務拓撲圖，在P1與P2路由器之間都是通過波分OSN8800傳輸，其中BC之間距離長達1155km，客戶反饋經過PE1和PE2承載的業務時延過大，且時延抖動過大。

（2）時延過大，且抖動范圍很大，前面分析指明，傳輸的時延主要有光纖傳輸時延、中間節點產生的時延，其中設備產生的處理和轉發時延都是微秒級的，排隊時延在于數據單板處理中配置QOS，緩存排查的時延。排查傳輸單板和業務配置，單板為TTX的OTU單板，業務為簡單透傳，沒有配置QOS和shaping。

圖2 承載網絡示意圖

（3）路徑時延指的是從源到宿的時間，測量過程主要是對開銷的處理。時延測量是測量ODUk端到端的雙向時延，如果路徑上存在ODUk SNCP保護，測量結果為當前工作路徑時延。

時延測量依賴客戶側有光信號輸入。測量過程自動在源端OTU單板下插PM層的時延測量開銷字節，中間網元透傳，宿端環回開銷字節。在測量結束之后自動恢復相關配置。

圖3 路徑時延測量原理圖

（4）P1與P2之間的距離為1155km，單向測量時延為6.3ms左右，與理論6ms差不多（加上設備單板的時延，更與理論值相符），且多次測量時延結果穩定。PE1與P1同站，PE1 ping P1時延都是在1ms內； P2同站PE2，PE2 ping P2時延也是在1ms內。但PE1 ping PE2時延很大，且有明顯抖動。

圖4 現網路徑PE1～PE2間E2E路徑時延ping測結果

3.3 問題根因及解決方案

最后通過排查定位，發現PE2路由器某單板芯片損壞，替換單板后問題解決。

定界是否是傳輸帶來的時延，最好的方法是撇開其他設備測量傳輸時延。該例子提供了U2000，可以提供免儀表的測試方法。

4 擁塞導致時延問題分析案例

4.1 問題現象

某客戶網絡某鏈路上報告警MPLS_TUNNEL_Excess。

4.2 問題分析：

（1）連續3個CV/FFD周期收到大于5個正確的CV/FFD報文時會出現MPLS_TUNNEL_Excess告警；

（2）首先使用Tunnel LSP ping測試Tunnel連通性正常；

（3）檢查Tunnel 源宿端 OAM屬性均為 “自適應 FFD 3.3ms” ，不存在兩端不一致情況；

（4）檢查源宿端是否有相同源節點ID和Tunnel ID情況，檢查結果表明Tunnel配置正常；

（5）以上檢查都正常，但是Tunnel告警不斷上報，表明設備確實在3個FFD周期也就是10ms內收到了多于5個的FFD OAM報文。懷疑該Tunnel 傳輸的報文有流量擁塞或延遲過大情況；

（6）檢查同路由的Tunnel從未上報異常告警，經過的站點也無FLOW_OVER告警；

（7）檢查Tunnel及其承載的PWE3業務 Qos發現，Tunnel和PWE3都設置了保證帶寬和峰值帶寬為2M bit/s，與客戶溝通將Tunnel Qos都改為無限制，發現MPLS_TUNNEL_Excess告警消除后不再上報；

（8）與客戶核實，該TUNNEL承載的PWE3大客戶業務為2M bit/s帶寬，最近由于該業務新下掛視頻，帶寬使用率較高。由于該Tunnel只承載一條PWE3，所以做業務時順帶把Tunnel也做了限速。

4.3 原因分析及解決方案

（1）為驗證是Tunnel限速導致的MPLS_TUNNEL_Excess告警上報。與客戶溝通，在申請時間對限速和不限速時的Tunnel性能進行測試比對；

（2）Tunnel保證帶寬和峰值帶寬限速為2M bit/s時，性能情況為：Tunnel丟包率：0.98%；Tunnel帶寬利用率：65.17%；Tunnel時延和時延抖動最大值：6.6ms左右。這說明該Tunnel在限速時發生了擁塞，時延達到了2個FFD周期。這導致有些設備在3個FFD周期只收到1個OAM報文，但是有些設備在3個FFD周期收到大于5個OAM報文，從而引起MPLS_TUNNEL_Excess頻繁上報。

5 總結

時延是指一個報文或分組從網絡的一端傳送到另一端所需要的時間。它包括了發送時延、傳播時延、處理時延、排隊時延（時延=發送時延+傳播時延+處理時延+排隊時延）。在傳輸距離長的時候主要考慮傳輸時延，在IP業務中需要考慮業務轉發處理中帶來的時延。定界是否為傳輸問題的最好辦法是通過分段ping測試，傳輸網絡和網管系統能夠提供免儀表的路徑時延測試功能、tunnel路徑和業務的TP-Assist測試時延功能。在不影響業務的情況下測試傳輸網絡的時延，解決好傳輸時延問題，有助于直接改善業務性能。