傳輸時延問題研究和解析

王鵬 薛凌云

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

0 引言

4G數(shù)據(jù)業(yè)務、VOLTE話音業(yè)務、互聯(lián)網(wǎng)視頻等業(yè)務對時延要求越來越高，傳輸系統(tǒng)對時延的影響也越來越凸顯，優(yōu)化和提升傳輸系統(tǒng)時延是改善業(yè)務感知的重要手段。

1 時延產(chǎn)生的原因分析及解決方案

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

產(chǎn)生原因：

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

解決方案：

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

1.2 網(wǎng)絡中間節(jié)點時產(chǎn)生的時延

1.2.1 處理時延

產(chǎn)生原因：

（1）路由器、交換機等網(wǎng)絡設備內(nèi)部的處理時延一般為2 ～ 20us；

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

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

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

解決方案：

硬件處理時長都很小，如果發(fā)現(xiàn)經(jīng)過每個硬件時延過大，可以通過替換單板來解決。

1.2.2 發(fā)送時延

產(chǎn)生原因：

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

解決方案：

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

1.2.3 報文排隊時延

產(chǎn)生原因：

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

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

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

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

解決方案：

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

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

產(chǎn)生原因：

（1）重傳時延

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

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

（2）兩端處理時延

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

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

解決方案：

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

2 FTP時延問題分析案例

2.1 問題現(xiàn)象

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

圖1 FTP問題組網(wǎng)示意圖

2.2 問題分析

排查組網(wǎng)：兩個站點經(jīng)過的公共路徑和設備都是華為OSN3500和 LAN Switch1。

帶寬配置：在OSN3500EGS4單板上綁定了一個VC4的帶寬，但上載速率最大只能到28M，下載速率只能到40M左右。排查OSN3500上沒有誤碼性能記錄，查看RMON流量統(tǒng)計，流量也沒有明顯超過帶寬，也沒有丟包的記錄?？蛻粢笙螺d帶寬要到100M。

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

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

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

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

2.3 解決方案及結論

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

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

3.1 問題現(xiàn)象

某客戶網(wǎng)絡，客戶反饋時延過大使得下游終端客戶業(yè)務受到影響。

3.2 問題分析

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

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

圖2 承載網(wǎng)絡示意圖

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

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

圖3 路徑時延測量原理圖

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

圖4 現(xiàn)網(wǎng)路徑PE1～PE2間E2E路徑時延ping測結果

3.3 問題根因及解決方案

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

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

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

4.1 問題現(xiàn)象

某客戶網(wǎng)絡某鏈路上報告警MPLS_TUNNEL_Excess。

4.2 問題分析：

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

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

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

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

（5）以上檢查都正常，但是Tunnel告警不斷上報，表明設備確實在3個FFD周期也就是10ms內(nèi)收到了多于5個的FFD OAM報文。懷疑該Tunnel 傳輸?shù)膱笪挠辛髁繐砣蜓舆t過大情況；

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

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

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

4.3 原因分析及解決方案

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

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

5 總結

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