移動(dòng)網(wǎng)絡(luò)中重傳超時(shí)問(wèn)題的研究

萬(wàn)文凱，汪海濤，姜 瑛，陳 星

（昆明理工大學(xué) 信息工程與自動(dòng)化學(xué)院，云南 昆明 650500）

移動(dòng)網(wǎng)絡(luò)中重傳超時(shí)問(wèn)題的研究

萬(wàn)文凱，汪海濤，姜 瑛，陳 星

（昆明理工大學(xué) 信息工程與自動(dòng)化學(xué)院，云南 昆明 650500）

作為廣泛使用的網(wǎng)絡(luò)傳輸控制協(xié)議，TCP（Transmission Control Protocol）在高速移動(dòng)網(wǎng)絡(luò)中遇到了新的性能瓶頸。首先由于移動(dòng)網(wǎng)絡(luò)中存在隨機(jī)位錯(cuò)誤導(dǎo)致的丟包，而TCP協(xié)議不能有效區(qū)分這類丟包與擁塞丟包，導(dǎo)致TCP頻繁的降低擁塞窗口無(wú)法有效利用移動(dòng)網(wǎng)絡(luò)的帶寬資源。其次，高速移動(dòng)網(wǎng)絡(luò)的發(fā)展使得帶寬時(shí)延積BDP（Bandwidth-Delay Product）進(jìn)一步增大，在發(fā)生丟包時(shí)TCP協(xié)議中的流量控制將導(dǎo)致性能瓶頸和易引起重傳超時(shí)。通過(guò)Wireshark工具抓取大量的tracing進(jìn)行分析，發(fā)現(xiàn)重傳超時(shí)的主要原因是重傳數(shù)據(jù)包再次被丟，而TCP又不能發(fā)現(xiàn)丟失原因，因此無(wú)法進(jìn)行再次重傳最終導(dǎo)致重傳超時(shí)。 針對(duì)這一問(wèn)題，本文提出的方法DTOR（Detect Timeout and Retransmission）可以幫助TCP檢測(cè)到重傳數(shù)據(jù)包再次丟失并觸發(fā)再次重傳，DTOR使網(wǎng)絡(luò)帶寬利用率提升了20%左右。

傳輸控制協(xié)議；移動(dòng)網(wǎng)絡(luò)；重傳超時(shí)

0 引言

研究顯示，作為廣泛使用的TCP協(xié)議在高速移動(dòng)網(wǎng)絡(luò)中遇到了新的性能瓶頸。例如，Mascolo等人[1]還有Fu和Liew[2]設(shè)計(jì)了新的方法來(lái)辨別網(wǎng)絡(luò)中的非擁塞丟包和擁塞丟包，防止不必要的降低擁塞窗口（CWnd）造成帶寬利用率損失。也有人在丟失重傳階段重新設(shè)計(jì)擁塞控制算法來(lái)提高TCP的帶寬利用率。

最近，Liu和Lee[3]還有Leong等人[4]提出了基于隊(duì)列長(zhǎng)度的自適應(yīng)丟失恢復(fù)算法來(lái)取代原先TCP中的丟失恢復(fù)算法，他們將數(shù)據(jù)包丟失和擁塞控制解耦，使傳輸速率或CWnd的調(diào)整在重傳階段或者發(fā)送新數(shù)據(jù)包時(shí)僅受所評(píng)估的鏈路中隊(duì)列長(zhǎng)度的影響。相比較傳統(tǒng)的TCP算法，他們的結(jié)果顯示，他們的方法能有效緩解在移動(dòng)網(wǎng)絡(luò)中因隨機(jī)丟包造成的帶寬利用率下降問(wèn)題。

為進(jìn)一步的提高帶寬利用率，Zha和Liu[5]提出了機(jī)會(huì)式重傳算法（OR）和新的發(fā)送緩存區(qū)動(dòng)態(tài)分配策略，來(lái)分別解決快速重傳階段的流量控制導(dǎo)致的性能瓶頸和application stall問(wèn)題。

實(shí)驗(yàn)中，在網(wǎng)絡(luò)帶寬為20 Mbps的環(huán)境下，通過(guò)測(cè)試數(shù)據(jù)來(lái)看，Zha和Liu[5]方案的帶寬利用率能達(dá)到 95.0%，似乎很好地解決了在丟失恢復(fù)階段隨機(jī)丟包帶來(lái)的帶寬利用率下降問(wèn)題。然而，當(dāng)我們把網(wǎng)絡(luò)帶寬提升到100 Mbps時(shí)，卻發(fā)現(xiàn)了一個(gè)新問(wèn)題——頻繁的重傳超時(shí)（RTO），致使帶寬利用率只能達(dá)到50%左右。通過(guò)實(shí)驗(yàn)數(shù)據(jù)分析，我們發(fā)現(xiàn)RTO問(wèn)題主要是由于在TCP丟失恢復(fù)階段的重傳數(shù)據(jù)包再次被丟失，而TCP發(fā)送方不知道重傳數(shù)據(jù)包再次丟失，從而無(wú)法重傳丟失的數(shù)據(jù)包。于是，我們提出了 DTOR，一個(gè)能判斷數(shù)據(jù)包丟失的原因，并且能觸發(fā)TCP發(fā)送方再次重傳數(shù)據(jù)包，緩解RTO的方法。重傳包丟失問(wèn)題的研究基本上是建立在工作[3]和[5]上的。

1 研究背景和相關(guān)工作

在這部分，我們首先回顧在當(dāng)前TCP擁塞控制中已實(shí)施的各類丟失恢復(fù)算法，及其在移動(dòng)網(wǎng)絡(luò)中低效率的原因。

1.1 快速恢復(fù)算法

Rate-Halving（RH）[7]和 proportional rate reduction（PRR）[6]分別是Linux內(nèi)核版本3.2之前和之后默認(rèn)的TCP快速恢復(fù)算法，當(dāng)它們根據(jù)收到的ACK或SACK[8]判斷有丟包時(shí)，不管是隨機(jī)丟包還是擁塞丟包，都會(huì)去降低 CWnd，如果是隨機(jī)丟包便會(huì)出現(xiàn)帶寬利用不充分的情形。

還有一類基于隊(duì)列長(zhǎng)度的自適應(yīng)丟失恢復(fù)算法，這類算法將 CWnd的調(diào)整與丟包解耦，CWnd的增減只與鏈路中的隊(duì)列長(zhǎng)度有關(guān)，如果隊(duì)列長(zhǎng)度能保證在瓶頸鏈路中一直有數(shù)據(jù)包傳送，那么帶寬將被充分利用。

由于我們沒(méi)能在 Linux內(nèi)核中找到基于隊(duì)列長(zhǎng)度丟失恢復(fù)算法的源碼，于是我們基于相似的思想自己設(shè)計(jì)了 Queue-length Adaptive Rate Reduction algorithm(QARR)，QARR是基于瓶頸鏈路排隊(duì)長(zhǎng)度檢測(cè)的快速恢復(fù)算法，QARR可以解決移動(dòng)網(wǎng)絡(luò)中隨機(jī)丟包帶來(lái)的性能問(wèn)題，QARR與RH和PRR相比主要的不同是QARR不依賴ssthresh來(lái)指導(dǎo)CWnd的調(diào)整，因?yàn)镃Wnd在重傳結(jié)束時(shí)不收斂到ssthresh，CWnd只受隊(duì)列長(zhǎng)度的影響。

當(dāng)TCP發(fā)送方重傳完所有需要被重傳的數(shù)據(jù)包后，將發(fā)送新數(shù)據(jù)包，但需要滿足下面兩個(gè)條件：

（a）已經(jīng)在網(wǎng)絡(luò)中的數(shù)據(jù)包數(shù)（inflight data）需要少于 CWnd，即 pipe＜CWnd，pipe表示在收到第i個(gè) ACK/DUPACK后網(wǎng)絡(luò)中已經(jīng)發(fā)出但還未被確認(rèn)的數(shù)據(jù)包的數(shù)量。

（b）新數(shù)據(jù)的序號(hào)不能超過(guò)接收方AWnd的限制。

QARR也會(huì)受到上文提到的條件a和b的限制，遇到AWnd瓶頸問(wèn)題。

1.2 機(jī)會(huì)式重傳算法與application stall

1.2.1 機(jī)會(huì)式重傳算法

Liu和 Lee[11,17]在高 BDP的移動(dòng)網(wǎng)絡(luò)環(huán)境下提出了機(jī)會(huì)式傳輸算法，Zha和Liu[5]在此基礎(chǔ)上進(jìn)行了擴(kuò)展，提出了OR算法來(lái)解決AWnd瓶頸問(wèn)題。OR利用接收方的處理能力，允許發(fā)送方在重傳階段發(fā)送序號(hào)超過(guò)AW nd右邊界的新數(shù)據(jù)包。在這個(gè)策略中必須謹(jǐn)慎的決定哪些新數(shù)據(jù)包能被發(fā)送。機(jī)會(huì)式重傳算法可以概括為如下步驟：

（1）對(duì)于每一個(gè)收到的重復(fù)確認(rèn)包，解析其中SACK段得到兩個(gè)信息：在接收緩存中的空洞數(shù)，也就是丟包數(shù)，用n1表示，和被收到的亂序數(shù)據(jù)包數(shù)，用n2表示。

（2）接著TCP發(fā)送方首先會(huì)重傳所有的丟包，如果接收方成功接收所有重傳的數(shù)據(jù)包，那么RW nd就可以向右移動(dòng)n1+n2個(gè)單位。

（3）最終能夠發(fā)送的數(shù)據(jù)量還受擁塞控制的限制，即使用OR算法后數(shù)據(jù)的發(fā)送受限于min(CWnd,Awnd+) n1+n2。

實(shí)際上，OR算法這么激進(jìn)，基本的假設(shè)有兩條：一是移動(dòng)設(shè)備具有足夠的處理能力，能夠在重傳包到達(dá)后及時(shí)的清空接收緩存，騰出空間給后面因OR算法而發(fā)送的n1+n2個(gè)新數(shù)據(jù)包；二是重傳數(shù)據(jù)包不會(huì)再次丟失，如果丟失就和 Linux內(nèi)核的處理方法一樣，等待超時(shí)。

1.2.2 Application stall

Application stall現(xiàn)象出現(xiàn)一般是由于（1）發(fā)送方不能發(fā)送新的數(shù)據(jù)包，（2）當(dāng)前的發(fā)送緩存機(jī)制效率低。對(duì)于（1）發(fā)送方不總是能發(fā)送數(shù)據(jù)，在2.2.1中，已通過(guò)OR算法解決了流量瓶頸這個(gè)問(wèn)題，對(duì)于情況（2），Zha和 Liu等人[5]給出了證明，將snd_buf的增長(zhǎng)因子從 2調(diào)整為 3，即 snd_buf=3*CWnd，這樣能有效的避免重傳階段的application stall現(xiàn)象，具體證明過(guò)程可以參看文獻(xiàn)[5]。

機(jī)會(huì)式重傳的提出和對(duì) Linux內(nèi)核發(fā)送緩存動(dòng)態(tài)分配策略的調(diào)整雖然很好地解決了網(wǎng)絡(luò)帶寬利用率低的問(wèn)題，但那也只是在丟包不顯著的環(huán)境下。

2 RTO問(wèn)題分析和解決方案

在帶寬為 20Mbps的情況下，使用 Zha和 Liu等人[5]的方法可以有效提高帶寬利用率，達(dá)到95.0%。然而，當(dāng)帶寬增加到100Mbps，丟包率進(jìn)一步增大時(shí)，會(huì)發(fā)生頻繁的RTO問(wèn)題，其帶寬利用率下降到了 50%左右。通過(guò)使用 Wireshark工具抓取大量日志分析，我們發(fā)現(xiàn)其原因在于使用 OR算法解除流量瓶頸問(wèn)題后，CW nd升上去了，而由此引發(fā)的重傳數(shù)據(jù)包再次丟失沒(méi)有觸發(fā) TCP發(fā)送方重傳，導(dǎo)致了超時(shí)。

2.1 有OR算法和沒(méi)OR算法的區(qū)別

首先看一下不加OR算法，TCP如何處理同一個(gè)數(shù)據(jù)包多次丟失的情形。如圖1所示，圖中顯示有兩個(gè)丟包。當(dāng)TCP發(fā)送方通過(guò)sack推斷出數(shù)據(jù)包丟失時(shí)，會(huì)立馬重傳丟失的數(shù)據(jù)包，接著在AW nd允許的范圍內(nèi)發(fā)送新數(shù)據(jù)包。一段時(shí)間后，如果新發(fā)送的數(shù)據(jù)包被SACKed了，但是重傳的數(shù)據(jù)包還沒(méi)被ACKed，那么TCP發(fā)送方就可以推斷出重傳的數(shù)據(jù)包又丟了，于是再次重傳，然后繼續(xù)發(fā)送新數(shù)據(jù)包，直到被 AWnd允許的數(shù)據(jù)包都被發(fā)送完，沒(méi)有新包可以發(fā)為止。此時(shí)，如果重傳的數(shù)據(jù)包還是沒(méi)收到，那么只能等超時(shí)了。但在實(shí)際中，超時(shí)概率是很小的，Linux內(nèi)核采取的是保守策略，當(dāng)發(fā)生丟包時(shí)，CWnd會(huì)被減小來(lái)緩解網(wǎng)絡(luò)的擁塞，從而保證重傳數(shù)據(jù)包能被收到。

使用了OR算法后的情形如圖2所示，其處理同一數(shù)據(jù)包多次丟失與不加 OR算法一樣。只是此時(shí)AW nd不再是瓶頸，當(dāng)被AW nd允許的數(shù)據(jù)包發(fā)送完后，為充分利用網(wǎng)絡(luò)帶寬，還可以繼續(xù)發(fā)送新數(shù)據(jù)包，新數(shù)據(jù)包數(shù)量等于在 2.2節(jié)中給出的n1+n2。通過(guò)對(duì)比可以發(fā)現(xiàn)，加了OR算法后如果重傳數(shù)據(jù)包不丟失，那么網(wǎng)絡(luò)將能獲得更高的帶寬利用率。

2.2 頻繁RTO問(wèn)題的形成

在圖2中，給出了使用OR算法丟包后接收方的RWnd圖，丟包后，RWnd的左邊界就被這個(gè)丟包固定。當(dāng)TCP發(fā)送方收到接收方回應(yīng)的sack時(shí)，根據(jù)解析sack段發(fā)現(xiàn)有數(shù)據(jù)包丟失，于是進(jìn)入快速重傳階段，首先重傳 RWnd左邊界這個(gè)丟失的數(shù)據(jù)包。由于使用了OR算法，假設(shè)重傳數(shù)據(jù)包不會(huì)再次丟失，接收方收到重傳數(shù)據(jù)包后能迅速處理RWnd內(nèi)的數(shù)據(jù)。這時(shí)發(fā)送方可以繼續(xù)發(fā)送數(shù)據(jù)包的數(shù)量記為S：

圖1 沒(méi)有 ORFig.1 Without OR

圖2 有ORFig.2 With OR

表達(dá)式（1）和（2）中的變量OR 表示使用了OR算法后額外可以發(fā)送的數(shù)據(jù)包數(shù)，snd_nxt表示將要發(fā)送的第一個(gè)新數(shù)據(jù)包的序號(hào)，snd-uua表示第一個(gè)丟失數(shù)據(jù)包的起始序號(hào)（也是RW nd的左邊界序號(hào)），highest_sack_seq表示發(fā)送緩存中已經(jīng)被發(fā)送方確認(rèn)接收的數(shù)據(jù)包的最高序號(hào)。經(jīng)過(guò)一段時(shí)間后，如果重傳的數(shù)據(jù)包被收到，那么此時(shí)的RW nd如圖3所示，RW nd向右滑動(dòng)，然后根據(jù)收到的sack繼續(xù)重傳下一個(gè)丟失的數(shù)據(jù)包。因?yàn)楦鶕?jù)機(jī)會(huì)式重傳的假設(shè)，認(rèn)為重傳包不會(huì)丟失和網(wǎng)絡(luò)設(shè)備有足夠的處理能力，采取的是激進(jìn)發(fā)送策略，當(dāng)收到重傳數(shù)據(jù)包后會(huì)立馬清理 RWnd。所以發(fā)送方并沒(méi)有像傳統(tǒng)方法那樣減小CWnd，控制網(wǎng)絡(luò)擁塞，而是為了充分利用帶寬，繼續(xù)發(fā)送 OR算法允許的新數(shù)據(jù)包。但是在有多種干擾因素存在的移動(dòng)網(wǎng)絡(luò)中，重傳數(shù)據(jù)包再次丟失是很有可能發(fā)生的，此時(shí)的接收方窗口情形會(huì)是圖4所示那樣。

圖4 重傳包丟失Fig.4 Retransmission packet loss

如圖4所示，當(dāng)RWnd右邊界內(nèi)的數(shù)據(jù)包被收到后，而左邊界這個(gè)數(shù)據(jù)包被重傳多次還沒(méi)收到時(shí)，RWnd內(nèi)將不再有新數(shù)據(jù)包觸發(fā)重傳 RWnd左邊界的這個(gè)數(shù)據(jù)包，因?yàn)榇藭r(shí) RWnd內(nèi)的數(shù)據(jù)包已發(fā)送完，正在發(fā)送的是OR區(qū)域內(nèi)的數(shù)據(jù)包。RWnd左邊界一直被那個(gè)重復(fù)丟失的數(shù)據(jù)包固定，不能向右滑動(dòng)，那么當(dāng)OR區(qū)域內(nèi)的數(shù)據(jù)包陸續(xù)到達(dá)接收方時(shí)，所以沒(méi)有空間容納 OR區(qū)域的數(shù)據(jù)包，那么只能將收到的 OR區(qū)域內(nèi)的數(shù)據(jù)包全部丟掉，也不能再次觸發(fā)發(fā)送方重傳。最后只能等到重傳超時(shí)，然后初始化cWnd，重新開始慢啟動(dòng)重傳所有的丟包，這樣就會(huì)不可避免的造成帶寬利用率下降。

2.3 RTO問(wèn)題的解決方案DTOR

我們知道，OR區(qū)域的數(shù)據(jù)包是RWnd外的數(shù)據(jù)包，在Linux內(nèi)核的設(shè)計(jì)中，認(rèn)為收到RW nd外的數(shù)據(jù)包是無(wú)效的，接收方會(huì)每收到一個(gè) OR區(qū)域的數(shù)據(jù)包回復(fù)發(fā)送方一個(gè) SACK，然后丟掉這些數(shù)據(jù)包。仔細(xì)分析接收方收到 OR區(qū)域的數(shù)據(jù)包后回復(fù)的這些SACK，會(huì)發(fā)現(xiàn)這些SACK和收到RWnd內(nèi)最后一個(gè)數(shù)據(jù)包時(shí)回復(fù)的SACK完全一樣。因?yàn)楫?dāng)

3 實(shí)施方案

為了便于對(duì)所提出的優(yōu)化技術(shù)和現(xiàn)有的丟失恢復(fù)算法進(jìn)行比較評(píng)估，我們對(duì)丟失恢復(fù)算法進(jìn)行了模塊化，以便在切換不同的丟失恢復(fù)算法時(shí)更加方便，不用重新編譯內(nèi)核。具體來(lái)說(shuō)，我們分別單獨(dú)在內(nèi)核模塊中實(shí)現(xiàn)了RH，PRR和QARR三個(gè)丟失恢復(fù)算法。一般來(lái)說(shuō)，TCP快速恢復(fù)模塊內(nèi)有兩個(gè)步驟：進(jìn)入或者退出快速恢復(fù)階段時(shí)的初始化，快速恢復(fù)階段對(duì)每個(gè)收到的ACK/SACK的處理。模塊化相比內(nèi)建模塊是否會(huì)帶來(lái)額外性能開銷，我們會(huì)在第5章給出測(cè)試數(shù)據(jù)說(shuō)明。

判斷重傳數(shù)據(jù)包丟失和觸發(fā)重傳的關(guān)鍵部分偽代碼如下：

Algorithm: DTOR

On each ACK/SACK:

begin

if !(flag and (FLAG_NOT_DUP or FLAG_SND_UNA_ADVANCED收到OR區(qū)域內(nèi)的數(shù)據(jù)包后，不會(huì)帶來(lái)RWnd任何的更新。而只要是收到的數(shù)據(jù)包在 RWnd內(nèi)，回復(fù)的SACK就會(huì)有變化。我們正好利用了這一點(diǎn)， 也就是前后SACK完全一樣，然后根據(jù)這個(gè)條件來(lái)判斷重傳的數(shù)據(jù)包又丟失了，于是觸發(fā)發(fā)送方重傳數(shù)據(jù)包，怎么判斷和觸發(fā)重傳在第4部分的實(shí)施方案會(huì)給出偽代碼進(jìn)行說(shuō)明。在這個(gè)時(shí)候重傳的數(shù)據(jù)包被丟的概率會(huì)大大降低，因?yàn)楦鶕?jù)實(shí)驗(yàn)觀察，等到接受方收到OR區(qū)域的數(shù)據(jù)包后回應(yīng)的SACK到達(dá)發(fā)送方時(shí)，停留在網(wǎng)絡(luò)中的已發(fā)送還未被 ACKed/SACKed的數(shù)據(jù)包已很少，此時(shí)網(wǎng)絡(luò)并不擁塞。

4 性能評(píng)估

為了評(píng)測(cè)本文提出的優(yōu)化方法，本文搭建了如圖5所示的測(cè)試環(huán)境。本文使用模擬環(huán)境而不是在真實(shí)的網(wǎng)絡(luò)環(huán)境中測(cè)試，原因是在真實(shí)環(huán)境中無(wú)法控制丟包的出現(xiàn)，不便于對(duì)比不同算法之間的性能。在配置模擬時(shí)，主要涉及往返時(shí)間R T T，丟包率/丟包數(shù)，帶寬等參數(shù)，參數(shù)設(shè)置主要參考[14,15]。如未特殊提到，參數(shù)具體的數(shù)值如表1所示。

需要注意的是， 移動(dòng)網(wǎng)絡(luò)的丟包率在不同環(huán)境下的差異較大。比如在地鐵內(nèi)的丟包率要遠(yuǎn)遠(yuǎn)高于在普通辦公場(chǎng)所內(nèi)的丟包率。因此在本文的模擬實(shí)

or FLAG_DATA_SACKED))

struct sk_buff *_skb = tcp_write_queue_head(sk)

tcp_for_write_queue_from(_skb, sk)

if TCP_SKB_CB(_skb)-＞seq ＞= highest sack sequence

break

if TCP_SKB_CB(_skb)-＞seq & TCPCB_SACKED_ACKED

continue

if !(TCP_SKB_CB(_skb)-＞sacked & TCPCB_LOST)

lost_out += tcp_skb_pcount(_skb)

TCP_SKB_CB(_skb)-＞sacked |= TCPCB_LOST

if (TCP_SKB_CB(_skb)-＞sacked & TCPCB_SACKED_RETRANS)

TCP_SKB_CB(_skb)-＞sacked &=～TCPCB_SACKED_RETRANS

retrans_out -= tcp_skb_pcount(_skb)

tcp_verify_retransmit_hint(tp, _skb)

end

接收方每收到一個(gè)數(shù)據(jù)包都會(huì)返回給發(fā)送方一個(gè)SACK，每一個(gè)SACK都帶有一個(gè)標(biāo)志位flag，這個(gè)flag記錄了接收方想要傳達(dá)給發(fā)送方的信息，比如收到的是否是一個(gè)重復(fù)數(shù)據(jù)包，或者是一個(gè)重傳的數(shù)據(jù)包，或者是確認(rèn)了某個(gè)新數(shù)據(jù)包等。

在本文的方法中，通過(guò)flag和Linux內(nèi)核預(yù)設(shè)的標(biāo)志狀態(tài)FLAG_NOT_DUP、FLAG_SND_UNA_ADVANCED和FLAG_DATA_SACKED進(jìn)行與或操作來(lái)判斷接收方收到SACK和上一個(gè)SACK是否完全一樣。因?yàn)閿?shù)據(jù)包是按順序發(fā)送的，如果前后SACK是一樣的，那么代表現(xiàn)在接收的是OR區(qū)域內(nèi)的數(shù)據(jù)包，RW nd區(qū)域內(nèi)的數(shù)據(jù)包已經(jīng)發(fā)送完，RW nd左邊界的重傳數(shù)據(jù)包還沒(méi)收到，可能已經(jīng)再次丟失，且不會(huì)有新SACK觸發(fā)重傳丟失的數(shù)據(jù)包。驗(yàn)中，也會(huì)對(duì)不同丟包率環(huán)境下的算法性能進(jìn)行對(duì)比。在圖6中的發(fā)送端和接收端使用的是Linux內(nèi)核3.10版本。發(fā)送端的峰值發(fā)送速度能達(dá)到940Mbps。

圖5 測(cè)試環(huán)境Fig.5 Test environment

表1 測(cè)試環(huán)境中的配置參數(shù)Table 1 System parameter used in the testbed

圖6 模塊化算法與內(nèi)建算法性能對(duì)比Fig.6 Pluggable TCP Loss recovery kernel module verification

4.1 模塊驗(yàn)證

在模擬環(huán)境中，本文使用tcpprobe內(nèi)核模塊在發(fā)送端抓取TCP流內(nèi)部的詳細(xì)參數(shù)變化，如擁cwnd的變化。在這一節(jié)中將驗(yàn)證TCP快速重傳算法模塊化的正確性和性能開銷。

表2 未使用OR算法的帶寬利用率Table 2 Bandwidth utilization with no OR

表3 使用OR算法的帶寬利用率Table 3 bandwidth utilization with OR

實(shí)驗(yàn)中選用的擁塞控制算法是CUBIC，快速重傳算法是PRR。這兩個(gè)算法均是Linux 3.10中默認(rèn)的算法。圖 6（左）是在模擬環(huán)境中測(cè)試一條 TCP流在0.001%至10%丟包率情況下，得到的網(wǎng)絡(luò)吞吐率結(jié)果。圖6（右）是在TCP流的5個(gè)特定時(shí)間點(diǎn)進(jìn)行丟包得到的 cwnd變化圖?？梢钥吹剿惴K化后與內(nèi)建的算法在性能開銷上沒(méi)有太大出入，所以不會(huì)引入額外的性能開銷。

這里約定，OR算法和application stall解決方案是捆綁在一起使用的，后面實(shí)驗(yàn)中說(shuō)的使用 OR算法是指這兩者都使用。

表4 未使用OR算法的帶寬利用率Table 4 bandwidth utilization with no OR

表5 使用OR算法后的帶寬利用率Table 5 bandwidth utilization with OR

4.2 OR算法對(duì)TCP性能的提升

實(shí)驗(yàn)測(cè)試中，我們首先在不同丟包率下使用了12種 TCP變體組合（擁塞控制算法有 CUBIC，Westwood，Veno和 Vegas，丟失恢復(fù)算法有 RH，PRR和QARR）來(lái)評(píng)估TCP的性能。為什么要這么組合，因?yàn)镃UBIC是當(dāng)前Linux內(nèi)核默認(rèn)的擁塞控制算法，TCP Westwood和 TCP Veno是專為移動(dòng)/無(wú)線網(wǎng)絡(luò)應(yīng)對(duì)非擁塞丟包而設(shè)計(jì)的，而 TCP Vegas是基于延遲的 TCP擁塞控制算法的代表。RH是Linux Kernel3.2之前的默認(rèn)丟失恢復(fù)算法，而PRR是 Linux kernel 3.2之后的默認(rèn)丟失恢復(fù)算法。QARR被廣泛應(yīng)用于最近提出的速率控制算法中。

表2中給出了在帶寬為 20Mbps環(huán)境下不使用OR算法的測(cè)試結(jié)果，可以看到，各類擁塞控算法與QARR的組合在三種不同丟包率環(huán)境下都要明顯要好于與RH和PRR的組合。因?yàn)镼ARR的CWnd變化只與鏈路排隊(duì)長(zhǎng)度有關(guān)，而不受丟包的影響，而PRR和 RH只要發(fā)現(xiàn)丟包都會(huì)去降低 CWnd。在移動(dòng)網(wǎng)絡(luò)中，很多丟包都不是因?yàn)榫W(wǎng)絡(luò)擁塞，而是一些外部環(huán)境導(dǎo)致的，稱為非擁塞丟包。如果是非擁塞丟包，那么就沒(méi)有必要減小擁塞窗口 CWnd，只需要重傳那些丟失的數(shù)據(jù)包即可。這樣可以保證高帶寬利用率，這也是QARR算法比RH和PRR要好的原因。

圖7 丟包率=0.05%Fig.7 lost rate=0.05%

圖8 丟包率=0.5%Fig.8 lost rate=0.5%

接下來(lái)我們測(cè)量了在帶寬為 20Mbps環(huán)境下使用OR算法后的情況，如表3所示，可以看到，各類擁塞控制算法與RH和PRR組合的帶寬利用率并沒(méi)有得到改善。因?yàn)?OR算法是用來(lái)解除流量瓶頸的，而RH和PRR嚴(yán)重受非擁塞丟包的影響，受限于擁塞控制瓶頸而不是流量瓶頸，自然加了 OR算法也沒(méi)作用。反觀QARR算法使用OR算法后，帶寬利用率明顯得到了提升，因?yàn)橹癚ARR是受到AW nd瓶頸的限制，現(xiàn)在加了OR算法后，AW nd瓶頸不再是限制，當(dāng)然帶寬利用率會(huì)進(jìn)一步提高。

4.3 頻繁重傳超時(shí)對(duì)TCP性能的影響

在帶寬為20 Mbps，丟包率為0.1%，往返延遲RTT為100 ms的環(huán)境下，在一個(gè)RTT內(nèi)的平均丟包數(shù)為0.18個(gè)，那么重傳數(shù)據(jù)包被丟失的概率就會(huì)更小，所以RTO問(wèn)題不明顯。在5.3這部分的測(cè)試環(huán)境都是在帶寬為100 Mbps環(huán)境下，考慮到在移動(dòng)網(wǎng)絡(luò)環(huán)境中造成隨機(jī)丟包的因素較多，所以將測(cè)試環(huán)境中的最大丟包率提高到 0.5%（現(xiàn)在 0.5%的丟包率在移動(dòng)網(wǎng)絡(luò)中已經(jīng)很常見），使重傳數(shù)據(jù)包多次丟失問(wèn)題更明顯，這時(shí)一個(gè)RTT內(nèi)的丟包數(shù)為4.37個(gè)，其他參數(shù)配置和在帶寬為20 Mbps環(huán)境下完全一樣。

表6 使用DTOR后的帶寬利用率Table 6 bandwidth utilization with no DTOR

因?yàn)镽H和PRR算法自身的限制，它們的帶寬利用率低不是受限于流量瓶頸，而我們?cè)诘?章給出的解決方案是針對(duì)解除流量瓶頸后引發(fā)頻繁的重傳超時(shí)，導(dǎo)致帶寬利用率下降這種情形提出的，所以我們將不再測(cè)試各類擁塞控制算法與RH和PRR的組合。

在同樣的丟包率下，網(wǎng)絡(luò)帶寬越大，丟包對(duì)網(wǎng)絡(luò)帶寬利用率造成的損失越明顯，如表4所示，在丟包率為0.05%，網(wǎng)絡(luò)帶寬為100Mbps的條件下，CUBIC+QARR的帶寬利用率只有66.2%，相比在帶寬為20Mbps的條件下，帶寬利用率下降了12.8%，VENO+QARR的帶寬利用率下降了27.1%。但只要丟包率不是很高，使用 OR算法后都能保證大幅度的提升帶寬利用率，如表5所示，在丟包率為0.05%和0.1%的條件下，擁塞控制算法與QARR組合的帶寬利用率都達(dá)到了90%以上。

當(dāng)丟包率上升到0.5%時(shí)，OR算法的問(wèn)題就顯現(xiàn)出來(lái)了，如表5所示， CUBIC+QARR+OR的帶寬利用率只有 52%左右， VENO+QARR+OR的帶寬利用率甚至下降到了35%，比不使用OR算法還要差。如果不啟用OR算法，TCP受限于流量瓶頸以至于CW nd升不上去，重傳數(shù)據(jù)包丟失的概率也自然就小了。

4.4 優(yōu)化技術(shù)對(duì)TCP性能的影響

在圖 7中，我們給出了在丟包率為0.05%的環(huán)境下，分別不使用OR算法、使用OR算法和使用DTOR這三種情況下的CW nd的波動(dòng)情況?？梢钥吹?，在丟包率不顯著的情況下，使用 OR算法沒(méi)有導(dǎo)致重傳超時(shí)，所以DTOR的表現(xiàn)和OR算法的表現(xiàn)基本一致。再看圖8，此時(shí)的丟包率為0.5%，使用OR算法相比不使用OR算法雖然CW nd升上去了，但同時(shí)也帶來(lái)了RTO問(wèn)題，而DTOR優(yōu)化機(jī)制既可以保證高吞吐率，又可以避免RTO。

如表6所示，給出了使用DTOR優(yōu)化技術(shù)后的帶寬利用率情況，在丟包率只有0.05%和0.1%時(shí)，網(wǎng)絡(luò)帶寬利用率都達(dá)到了 92%以上，例如 TCP Westwood+QARR在丟包率為0.1%時(shí)的帶寬利用率為92.4%， TCP VENO+QARR在丟包率為0.05%和0.1%的環(huán)境下，帶寬利用率分別達(dá)到了 95%和94.7%。因?yàn)橹貍靼粊G失的概率很小，開啟OR算法后網(wǎng)絡(luò)帶寬幾乎被充分利用了，所以使用 DTOR優(yōu)化技術(shù)也沒(méi)有多少提升空間。

當(dāng)丟包率上升到 0.5%時(shí)，使用 DTOR后CUBIC+QARR的帶寬利用率上升到了 70%左右，相比不使用DTOR優(yōu)化技術(shù)帶寬利用率提升了20%左右，TCP VENO+QARR的帶寬利用率甚至提升了30%以上。但即便使用 DTOR優(yōu)化技術(shù)消除了 OR優(yōu)化算法帶來(lái)的頻繁重傳超時(shí)問(wèn)題，帶寬利用率也只有70%左右，還有30%的損失。如圖3和圖4所示，因?yàn)橹貍鲾?shù)據(jù)包的多次丟失，導(dǎo)致 OR區(qū)域內(nèi)的大量數(shù)據(jù)包被TCP接收端丟掉，這些大量被丟棄的數(shù)據(jù)包也是需要被重傳的，而重傳數(shù)據(jù)包是不計(jì)算在帶寬利用率內(nèi)的。

5 結(jié)束語(yǔ)

通過(guò)控制網(wǎng)絡(luò)擁塞來(lái)保證網(wǎng)絡(luò)的高吞吐率、低延遲一直是一個(gè)熱點(diǎn)研究領(lǐng)域。在這篇文章中，我們提出了一個(gè)優(yōu)化方法DTOR來(lái)解決重傳數(shù)據(jù)包多次丟失帶來(lái)的頻繁重傳超時(shí)問(wèn)題，從而進(jìn)一步提高網(wǎng)絡(luò)帶寬利用率。在后面，我們會(huì)繼續(xù)針對(duì)移動(dòng)網(wǎng)絡(luò)展開更深入的研究。

[1] Mascolo S, Casetti C, Gerla M, et al. TCP westwood: Bandwidth estimation for enhanced transport over wireless links[C]//Proceedings of the 7th annual international conference on Mobile computing and networking. ACM, 2001: 287-297.

[2] Fu, Cheng Peng, and Soung C. Liew. TCP Veno: TCP enhancement for transmission over wireless access networks[C]//IEEE Journal on selected areas in communications, 2003,vol.21(2): 216-228.

[3] Liu K, Lee J Y B. Achieving high throughput and low delay by accurately regulating link queue length over mobile data network[C]//Wireless and Mobile Computing, Networking and Communications (WiMob), 2014 IEEE 10th International Conference on. IEEE, 2014: 562-569.

[4] Leong W K, Xu Y, Leong B, et al. Mitigating egregious ACK delays in cellular data networks by eliminating TCP ACK clocking[C]//Network Protocols (ICNP), 2013 21st IEEE International Conference on. IEEE, 2014: 1-10.

[5] Zha Z, Liu K, Fu B, et al. Optimizing TCP loss recovery performance over mobile data networks[C]//Sensing,Communication, and Networking (SECON), 2015 12th Annual IEEE International Conference on. IEEE, 2015: 471-479.

[6] N. Dukkipati, M. Mathis, Y. Cheng, and M. Ghobadi. Proportional rate reduction for TCP[C]// Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference,2011: 155-170.

[7] M. Mathis and J. Mahdavi, “TCP rate-halving with bounding parameters.” Available: http://www.psc.edu/networking/papers/FACKnotes/current/.

[8] Mathis M, Mahdavi J, Floyd S, et al. TCP selective acknowledgment options[R]. Oct 1996.

[9] M. Mathis, J. Mahdavi. Refining TCP Congestion Control[C]//in ACM SIGCOMM Computer Communication Review,1996, vol.26(4):281-291

[10] E. Blanton, M. Allman, K. Fall and L. Wang, “A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP,” Request for Comments 3517, 2003.

[11] Liu K, Lee J Y B. Mobile accelerator: A new approach to improve TCP performance in mobile data networks[C]//Wireless Communications and Mobile Computing Conference (IWCMC), 2011 7th International. IEEE, 2011: 2174-2180.

[12] (2015) Centos homepage. [Online]. Available: https://www.centos.org/.[13] Brakmo, Lawrence S., and Larry L. Peterson. "TCP Vegas:End to end congestion avoidance on a global Internet." IEEE Journal on selected Areas in communications, 1995, vol.13(8):1465-1480.

[14] Huang, Junxian, et al. Anatomizing application performance differences on smartphones[C]//Proceedings of the 8th international conference on Mobile systems, applications, and services. ACM, 2010:165-178.

[15] Heikkinen, Mikko VJ, and Arthur W. Berger. Comparison of user traffic characteristics on mobile-access versus fixedaccess networks[C]// International Conference on Passive and Active Network Measurement. Springer Berlin Heidelberg, 2012:32-41.

[16] Ha, Sangtae, Injong Rhee, and Lisong Xu. "CUBIC: a new TCP-friendly high-speed TCP variant." ACM SIGOPS Operating Systems Review, 2008, vol.42(5): 64-74.

[17] K. Liu and J. Y. B. Lee. On Improving TCP Performance in Mobile Data Networks[C]// IEEE Transactions on Mobile Computing, 2016, vol. 15(10): 2522-2536.

[18] S. Hemminger et al., “Network emulation with NetEm,” in Linux Conf Au. Citeseer, April 2005: 18-23.

[19] The netfilter.org: iptables project homepage. [Online].Available: http://www.netfilter.org/projects/iptables/index.html

[20] (2015)2013-2014中國(guó)移動(dòng)互聯(lián)網(wǎng)藍(lán)皮書. [Online].Available:http://www.dcci.com.cn/media/download/63508a8 b6bbd2a88ab51bd3f3147b19d7e4c.pdf

Research on Retransmission Timeout over Mobile Data Networks

WAN Wen-kai, WANG Hai-tao, JIANG Ying, CHEN Xing
(Faculty of Information Engineering and Automation, Kunming University of Science and Technology, Kunming 650500, China)

Recent advances in high-speed mobile networks have revealed new bottlenecks in ubiquitous TCP protocol deployed in the Internet. First, due to the existence of random bit errors in the mobile network, and TCP protocol can’t effectively distinguish non-congestive loss from congestive loss, resulting in TCP frequently reduce the congestion window, and can’t effectively use the mobile network bandwidth resources. Second, the development of high-speed mobile network makes the bandwidth delay BDP (Bandwidth-Delay Product) to further increase,when the packet loss occurs, TCP protocol flow control will also lead to performance bottlenecks and retransmission timeout. Using the Wireshark tool to capture a large number of tracing for analysis, found the main reason for the retransmission timeout is that the retransmission packet is lost again, and TCP sender can’t find the cause to the loss,so loss packet can’t be retransmitted again by TCP sender, eventually leading to RTO. In response to this problem,Optimization techniques - DTOR (Detect Timeout and Retransmission) can help TCP detect that the retransmitted packet is loss again and triggers TCP sender retransmission again. Using emulated experiments showed that the proposed optimization techniques sufficiently utilize the bandwidth.

TCP; Mobile data network; Retransmission timeout

retransmission packet

TP182

A

10.3969/j.issn.1003-6970.2017.12.006

本文著錄格式：萬(wàn)文凱，汪海濤，姜瑛. 移動(dòng)網(wǎng)絡(luò)中重傳超時(shí)問(wèn)題的研究[J]. 軟件，2017，38（12）：29-36

國(guó)家自然科學(xué)基金(61462049)

萬(wàn)文凱(1992-)，男，碩士，主要研究方向：數(shù)據(jù)中心網(wǎng)絡(luò)。

汪海濤，副教授，主要研究方向：軟件工程。