移动网络中重传超时问题的研究

万文凯，汪海涛，姜 瑛，陈 星

（昆明理工大学 信息工程与自动化学院，云南 昆明 650500）

移动网络中重传超时问题的研究

万文凯，汪海涛，姜 瑛，陈 星

（昆明理工大学 信息工程与自动化学院，云南 昆明 650500）

作为广泛使用的网络传输控制协议，TCP（Transmission Control Protocol）在高速移动网络中遇到了新的性能瓶颈。首先由于移动网络中存在随机位错误导致的丢包，而TCP协议不能有效区分这类丢包与拥塞丢包，导致TCP频繁的降低拥塞窗口无法有效利用移动网络的带宽资源。其次，高速移动网络的发展使得带宽时延积BDP（Bandwidth-Delay Product）进一步增大，在发生丢包时TCP协议中的流量控制将导致性能瓶颈和易引起重传超时。通过Wireshark工具抓取大量的tracing进行分析，发现重传超时的主要原因是重传数据包再次被丢，而TCP又不能发现丢失原因，因此无法进行再次重传最终导致重传超时。 针对这一问题，本文提出的方法DTOR（Detect Timeout and Retransmission）可以帮助TCP检测到重传数据包再次丢失并触发再次重传，DTOR使网络带宽利用率提升了20%左右。

传输控制协议；移动网络；重传超时

0 引言

研究显示，作为广泛使用的TCP协议在高速移动网络中遇到了新的性能瓶颈。例如，Mascolo等人[1]还有Fu和Liew[2]设计了新的方法来辨别网络中的非拥塞丢包和拥塞丢包，防止不必要的降低拥塞窗口（CWnd）造成带宽利用率损失。也有人在丢失重传阶段重新设计拥塞控制算法来提高TCP的带宽利用率。

最近，Liu和Lee[3]还有Leong等人[4]提出了基于队列长度的自适应丢失恢复算法来取代原先TCP中的丢失恢复算法，他们将数据包丢失和拥塞控制解耦，使传输速率或CWnd的调整在重传阶段或者发送新数据包时仅受所评估的链路中队列长度的影响。相比较传统的TCP算法，他们的结果显示，他们的方法能有效缓解在移动网络中因随机丢包造成的带宽利用率下降问题。

为进一步的提高带宽利用率，Zha和Liu[5]提出了机会式重传算法（OR）和新的发送缓存区动态分配策略，来分别解决快速重传阶段的流量控制导致的性能瓶颈和application stall问题。

实验中，在网络带宽为20 Mbps的环境下，通过测试数据来看，Zha和Liu[5]方案的带宽利用率能达到 95.0%，似乎很好地解决了在丢失恢复阶段随机丢包带来的带宽利用率下降问题。然而，当我们把网络带宽提升到100 Mbps时，却发现了一个新问题——频繁的重传超时（RTO），致使带宽利用率只能达到50%左右。通过实验数据分析，我们发现RTO问题主要是由于在TCP丢失恢复阶段的重传数据包再次被丢失，而TCP发送方不知道重传数据包再次丢失，从而无法重传丢失的数据包。于是，我们提出了 DTOR，一个能判断数据包丢失的原因，并且能触发TCP发送方再次重传数据包，缓解RTO的方法。重传包丢失问题的研究基本上是建立在工作[3]和[5]上的。

1 研究背景和相关工作

在这部分，我们首先回顾在当前TCP拥塞控制中已实施的各类丢失恢复算法，及其在移动网络中低效率的原因。

1.1 快速恢复算法

Rate-Halving（RH）[7]和 proportional rate reduction（PRR）[6]分别是Linux内核版本3.2之前和之后默认的TCP快速恢复算法，当它们根据收到的ACK或SACK[8]判断有丢包时，不管是随机丢包还是拥塞丢包，都会去降低 CWnd，如果是随机丢包便会出现带宽利用不充分的情形。

还有一类基于队列长度的自适应丢失恢复算法，这类算法将 CWnd的调整与丢包解耦，CWnd的增减只与链路中的队列长度有关，如果队列长度能保证在瓶颈链路中一直有数据包传送，那么带宽将被充分利用。

由于我们没能在 Linux内核中找到基于队列长度丢失恢复算法的源码，于是我们基于相似的思想自己设计了 Queue-length Adaptive Rate Reduction algorithm(QARR)，QARR是基于瓶颈链路排队长度检测的快速恢复算法，QARR可以解决移动网络中随机丢包带来的性能问题，QARR与RH和PRR相比主要的不同是QARR不依赖ssthresh来指导CWnd的调整，因为CWnd在重传结束时不收敛到ssthresh，CWnd只受队列长度的影响。

当TCP发送方重传完所有需要被重传的数据包后，将发送新数据包，但需要满足下面两个条件：

（a）已经在网络中的数据包数（inflight data）需要少于 CWnd，即 pipe＜CWnd，pipe表示在收到第i个 ACK/DUPACK后网络中已经发出但还未被确认的数据包的数量。

（b）新数据的序号不能超过接收方AWnd的限制。

QARR也会受到上文提到的条件a和b的限制，遇到AWnd瓶颈问题。

1.2 机会式重传算法与application stall

1.2.1 机会式重传算法

Liu和 Lee[11,17]在高 BDP的移动网络环境下提出了机会式传输算法，Zha和Liu[5]在此基础上进行了扩展，提出了OR算法来解决AWnd瓶颈问题。OR利用接收方的处理能力，允许发送方在重传阶段发送序号超过AW nd右边界的新数据包。在这个策略中必须谨慎的决定哪些新数据包能被发送。机会式重传算法可以概括为如下步骤：

（1）对于每一个收到的重复确认包，解析其中SACK段得到两个信息：在接收缓存中的空洞数，也就是丢包数，用n1表示，和被收到的乱序数据包数，用n2表示。

（2）接着TCP发送方首先会重传所有的丢包，如果接收方成功接收所有重传的数据包，那么RW nd就可以向右移动n1+n2个单位。

（3）最终能够发送的数据量还受拥塞控制的限制，即使用OR算法后数据的发送受限于min(CWnd,Awnd+) n1+n2。

实际上，OR算法这么激进，基本的假设有两条：一是移动设备具有足够的处理能力，能够在重传包到达后及时的清空接收缓存，腾出空间给后面因OR算法而发送的n1+n2个新数据包；二是重传数据包不会再次丢失，如果丢失就和 Linux内核的处理方法一样，等待超时。

1.2.2 Application stall

Application stall现象出现一般是由于（1）发送方不能发送新的数据包，（2）当前的发送缓存机制效率低。对于（1）发送方不总是能发送数据，在2.2.1中，已通过OR算法解决了流量瓶颈这个问题，对于情况（2），Zha和 Liu等人[5]给出了证明，将snd_buf的增长因子从 2调整为 3，即 snd_buf=3*CWnd，这样能有效的避免重传阶段的application stall现象，具体证明过程可以参看文献[5]。

机会式重传的提出和对 Linux内核发送缓存动态分配策略的调整虽然很好地解决了网络带宽利用率低的问题，但那也只是在丢包不显著的环境下。

2 RTO问题分析和解决方案

在带宽为 20Mbps的情况下，使用 Zha和 Liu等人[5]的方法可以有效提高带宽利用率，达到95.0%。然而，当带宽增加到100Mbps，丢包率进一步增大时，会发生频繁的RTO问题，其带宽利用率下降到了 50%左右。通过使用 Wireshark工具抓取大量日志分析，我们发现其原因在于使用 OR算法解除流量瓶颈问题后，CW nd升上去了，而由此引发的重传数据包再次丢失没有触发 TCP发送方重传，导致了超时。

2.1 有OR算法和没OR算法的区别

首先看一下不加OR算法，TCP如何处理同一个数据包多次丢失的情形。如图1所示，图中显示有两个丢包。当TCP发送方通过sack推断出数据包丢失时，会立马重传丢失的数据包，接着在AW nd允许的范围内发送新数据包。一段时间后，如果新发送的数据包被SACKed了，但是重传的数据包还没被ACKed，那么TCP发送方就可以推断出重传的数据包又丢了，于是再次重传，然后继续发送新数据包，直到被 AWnd允许的数据包都被发送完，没有新包可以发为止。此时，如果重传的数据包还是没收到，那么只能等超时了。但在实际中，超时概率是很小的，Linux内核采取的是保守策略，当发生丢包时，CWnd会被减小来缓解网络的拥塞，从而保证重传数据包能被收到。

使用了OR算法后的情形如图2所示，其处理同一数据包多次丢失与不加 OR算法一样。只是此时AW nd不再是瓶颈，当被AW nd允许的数据包发送完后，为充分利用网络带宽，还可以继续发送新数据包，新数据包数量等于在 2.2节中给出的n1+n2。通过对比可以发现，加了OR算法后如果重传数据包不丢失，那么网络将能获得更高的带宽利用率。

2.2 频繁RTO问题的形成

在图2中，给出了使用OR算法丢包后接收方的RWnd图，丢包后，RWnd的左边界就被这个丢包固定。当TCP发送方收到接收方回应的sack时，根据解析sack段发现有数据包丢失，于是进入快速重传阶段，首先重传 RWnd左边界这个丢失的数据包。由于使用了OR算法，假设重传数据包不会再次丢失，接收方收到重传数据包后能迅速处理RWnd内的数据。这时发送方可以继续发送数据包的数量记为S：

图1 没有 ORFig.1 Without OR

图2 有ORFig.2 With OR

表达式（1）和（2）中的变量OR 表示使用了OR算法后额外可以发送的数据包数，snd_nxt表示将要发送的第一个新数据包的序号，snd-uua表示第一个丢失数据包的起始序号（也是RW nd的左边界序号），highest_sack_seq表示发送缓存中已经被发送方确认接收的数据包的最高序号。经过一段时间后，如果重传的数据包被收到，那么此时的RW nd如图3所示，RW nd向右滑动，然后根据收到的sack继续重传下一个丢失的数据包。因为根据机会式重传的假设，认为重传包不会丢失和网络设备有足够的处理能力，采取的是激进发送策略，当收到重传数据包后会立马清理 RWnd。所以发送方并没有像传统方法那样减小CWnd，控制网络拥塞，而是为了充分利用带宽，继续发送 OR算法允许的新数据包。但是在有多种干扰因素存在的移动网络中，重传数据包再次丢失是很有可能发生的，此时的接收方窗口情形会是图4所示那样。

图4 重传包丢失Fig.4 Retransmission packet loss

如图4所示，当RWnd右边界内的数据包被收到后，而左边界这个数据包被重传多次还没收到时，RWnd内将不再有新数据包触发重传 RWnd左边界的这个数据包，因为此时 RWnd内的数据包已发送完，正在发送的是OR区域内的数据包。RWnd左边界一直被那个重复丢失的数据包固定，不能向右滑动，那么当OR区域内的数据包陆续到达接收方时，所以没有空间容纳 OR区域的数据包，那么只能将收到的 OR区域内的数据包全部丢掉，也不能再次触发发送方重传。最后只能等到重传超时，然后初始化cWnd，重新开始慢启动重传所有的丢包，这样就会不可避免的造成带宽利用率下降。

2.3 RTO问题的解决方案DTOR

我们知道，OR区域的数据包是RWnd外的数据包，在Linux内核的设计中，认为收到RW nd外的数据包是无效的，接收方会每收到一个 OR区域的数据包回复发送方一个 SACK，然后丢掉这些数据包。仔细分析接收方收到 OR区域的数据包后回复的这些SACK，会发现这些SACK和收到RWnd内最后一个数据包时回复的SACK完全一样。因为当

3 实施方案

为了便于对所提出的优化技术和现有的丢失恢复算法进行比较评估，我们对丢失恢复算法进行了模块化，以便在切换不同的丢失恢复算法时更加方便，不用重新编译内核。具体来说，我们分别单独在内核模块中实现了RH，PRR和QARR三个丢失恢复算法。一般来说，TCP快速恢复模块内有两个步骤：进入或者退出快速恢复阶段时的初始化，快速恢复阶段对每个收到的ACK/SACK的处理。模块化相比內建模块是否会带来额外性能开销，我们会在第5章给出测试数据说明。

判断重传数据包丢失和触发重传的关键部分伪代码如下：

Algorithm: DTOR

On each ACK/SACK:

begin

if !(flag and (FLAG_NOT_DUP or FLAG_SND_UNA_ADVANCED收到OR区域内的数据包后，不会带来RWnd任何的更新。而只要是收到的数据包在 RWnd内，回复的SACK就会有变化。我们正好利用了这一点， 也就是前后SACK完全一样，然后根据这个条件来判断重传的数据包又丢失了，于是触发发送方重传数据包，怎么判断和触发重传在第4部分的实施方案会给出伪代码进行说明。在这个时候重传的数据包被丢的概率会大大降低，因为根据实验观察，等到接受方收到OR区域的数据包后回应的SACK到达发送方时，停留在网络中的已发送还未被 ACKed/SACKed的数据包已很少，此时网络并不拥塞。

4 性能评估

为了评测本文提出的优化方法，本文搭建了如图5所示的测试环境。本文使用模拟环境而不是在真实的网络环境中测试，原因是在真实环境中无法控制丢包的出现，不便于对比不同算法之间的性能。在配置模拟时，主要涉及往返时间R T T，丢包率/丢包数，带宽等参数，参数设置主要参考[14,15]。如未特殊提到，参数具体的数值如表1所示。

需要注意的是， 移动网络的丢包率在不同环境下的差异较大。比如在地铁内的丢包率要远远高于在普通办公场所内的丢包率。因此在本文的模拟实

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

接收方每收到一个数据包都会返回给发送方一个SACK，每一个SACK都带有一个标志位flag，这个flag记录了接收方想要传达给发送方的信息，比如收到的是否是一个重复数据包，或者是一个重传的数据包，或者是确认了某个新数据包等。

在本文的方法中，通过flag和Linux内核预设的标志状态FLAG_NOT_DUP、FLAG_SND_UNA_ADVANCED和FLAG_DATA_SACKED进行与或操作来判断接收方收到SACK和上一个SACK是否完全一样。因为数据包是按顺序发送的，如果前后SACK是一样的，那么代表现在接收的是OR区域内的数据包，RW nd区域内的数据包已经发送完，RW nd左边界的重传数据包还没收到，可能已经再次丢失，且不会有新SACK触发重传丢失的数据包。验中，也会对不同丢包率环境下的算法性能进行对比。在图6中的发送端和接收端使用的是Linux内核3.10版本。发送端的峰值发送速度能达到940Mbps。

图5 测试环境Fig.5 Test environment

表1 测试环境中的配置参数Table 1 System parameter used in the testbed

图6 模块化算法与內建算法性能对比Fig.6 Pluggable TCP Loss recovery kernel module verification

4.1 模块验证

在模拟环境中，本文使用tcpprobe内核模块在发送端抓取TCP流内部的详细参数变化，如拥cwnd的变化。在这一节中将验证TCP快速重传算法模块化的正确性和性能开销。

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

表3 使用OR算法的带宽利用率Table 3 bandwidth utilization with OR

实验中选用的拥塞控制算法是CUBIC，快速重传算法是PRR。这两个算法均是Linux 3.10中默认的算法。图 6（左）是在模拟环境中测试一条 TCP流在0.001%至10%丢包率情况下，得到的网络吞吐率结果。图6（右）是在TCP流的5个特定时间点进行丢包得到的 cwnd变化图。可以看到算法模块化后与內建的算法在性能开销上没有太大出入，所以不会引入额外的性能开销。

这里约定，OR算法和application stall解决方案是捆绑在一起使用的，后面实验中说的使用 OR算法是指这两者都使用。

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

表5 使用OR算法后的带宽利用率Table 5 bandwidth utilization with OR

4.2 OR算法对TCP性能的提升

实验测试中，我们首先在不同丢包率下使用了12种 TCP变体组合（拥塞控制算法有 CUBIC，Westwood，Veno和 Vegas，丢失恢复算法有 RH，PRR和QARR）来评估TCP的性能。为什么要这么组合，因为CUBIC是当前Linux内核默认的拥塞控制算法，TCP Westwood和 TCP Veno是专为移动/无线网络应对非拥塞丢包而设计的，而 TCP Vegas是基于延迟的 TCP拥塞控制算法的代表。RH是Linux Kernel3.2之前的默认丢失恢复算法，而PRR是 Linux kernel 3.2之后的默认丢失恢复算法。QARR被广泛应用于最近提出的速率控制算法中。

表2中给出了在带宽为 20Mbps环境下不使用OR算法的测试结果，可以看到，各类拥塞控算法与QARR的组合在三种不同丢包率环境下都要明显要好于与RH和PRR的组合。因为QARR的CWnd变化只与链路排队长度有关，而不受丢包的影响，而PRR和 RH只要发现丢包都会去降低 CWnd。在移动网络中，很多丢包都不是因为网络拥塞，而是一些外部环境导致的，称为非拥塞丢包。如果是非拥塞丢包，那么就没有必要减小拥塞窗口 CWnd，只需要重传那些丢失的数据包即可。这样可以保证高带宽利用率，这也是QARR算法比RH和PRR要好的原因。

图7 丢包率=0.05%Fig.7 lost rate=0.05%

图8 丢包率=0.5%Fig.8 lost rate=0.5%

接下来我们测量了在带宽为 20Mbps环境下使用OR算法后的情况，如表3所示，可以看到，各类拥塞控制算法与RH和PRR组合的带宽利用率并没有得到改善。因为 OR算法是用来解除流量瓶颈的，而RH和PRR严重受非拥塞丢包的影响，受限于拥塞控制瓶颈而不是流量瓶颈，自然加了 OR算法也没作用。反观QARR算法使用OR算法后，带宽利用率明显得到了提升，因为之前QARR是受到AW nd瓶颈的限制，现在加了OR算法后，AW nd瓶颈不再是限制，当然带宽利用率会进一步提高。

4.3 频繁重传超时对TCP性能的影响

在带宽为20 Mbps，丢包率为0.1%，往返延迟RTT为100 ms的环境下，在一个RTT内的平均丢包数为0.18个，那么重传数据包被丢失的概率就会更小，所以RTO问题不明显。在5.3这部分的测试环境都是在带宽为100 Mbps环境下，考虑到在移动网络环境中造成随机丢包的因素较多，所以将测试环境中的最大丢包率提高到 0.5%（现在 0.5%的丢包率在移动网络中已经很常见），使重传数据包多次丢失问题更明显，这时一个RTT内的丢包数为4.37个，其他参数配置和在带宽为20 Mbps环境下完全一样。

表6 使用DTOR后的带宽利用率Table 6 bandwidth utilization with no DTOR

因为RH和PRR算法自身的限制，它们的带宽利用率低不是受限于流量瓶颈，而我们在第3章给出的解决方案是针对解除流量瓶颈后引发频繁的重传超时，导致带宽利用率下降这种情形提出的，所以我们将不再测试各类拥塞控制算法与RH和PRR的组合。

在同样的丢包率下，网络带宽越大，丢包对网络带宽利用率造成的损失越明显，如表4所示，在丢包率为0.05%，网络带宽为100Mbps的条件下，CUBIC+QARR的带宽利用率只有66.2%，相比在带宽为20Mbps的条件下，带宽利用率下降了12.8%，VENO+QARR的带宽利用率下降了27.1%。但只要丢包率不是很高，使用 OR算法后都能保证大幅度的提升带宽利用率，如表5所示，在丢包率为0.05%和0.1%的条件下，拥塞控制算法与QARR组合的带宽利用率都达到了90%以上。

当丢包率上升到0.5%时，OR算法的问题就显现出来了，如表5所示， CUBIC+QARR+OR的带宽利用率只有 52%左右， VENO+QARR+OR的带宽利用率甚至下降到了35%，比不使用OR算法还要差。如果不启用OR算法，TCP受限于流量瓶颈以至于CW nd升不上去，重传数据包丢失的概率也自然就小了。

4.4 优化技术对TCP性能的影响

在图 7中，我们给出了在丢包率为0.05%的环境下，分别不使用OR算法、使用OR算法和使用DTOR这三种情况下的CW nd的波动情况。可以看到，在丢包率不显著的情况下，使用 OR算法没有导致重传超时，所以DTOR的表现和OR算法的表现基本一致。再看图8，此时的丢包率为0.5%，使用OR算法相比不使用OR算法虽然CW nd升上去了，但同时也带来了RTO问题，而DTOR优化机制既可以保证高吞吐率，又可以避免RTO。

如表6所示，给出了使用DTOR优化技术后的带宽利用率情况，在丢包率只有0.05%和0.1%时，网络带宽利用率都达到了 92%以上，例如 TCP Westwood+QARR在丢包率为0.1%时的带宽利用率为92.4%， TCP VENO+QARR在丢包率为0.05%和0.1%的环境下，带宽利用率分别达到了 95%和94.7%。因为重传包被丢失的概率很小，开启OR算法后网络带宽几乎被充分利用了，所以使用 DTOR优化技术也没有多少提升空间。

当丢包率上升到 0.5%时，使用 DTOR后CUBIC+QARR的带宽利用率上升到了 70%左右，相比不使用DTOR优化技术带宽利用率提升了20%左右，TCP VENO+QARR的带宽利用率甚至提升了30%以上。但即便使用 DTOR优化技术消除了 OR优化算法带来的频繁重传超时问题，带宽利用率也只有70%左右，还有30%的损失。如图3和图4所示，因为重传数据包的多次丢失，导致 OR区域内的大量数据包被TCP接收端丢掉，这些大量被丢弃的数据包也是需要被重传的，而重传数据包是不计算在带宽利用率内的。

5 结束语

通过控制网络拥塞来保证网络的高吞吐率、低延迟一直是一个热点研究领域。在这篇文章中，我们提出了一个优化方法DTOR来解决重传数据包多次丢失带来的频繁重传超时问题，从而进一步提高网络带宽利用率。在后面，我们会继续针对移动网络展开更深入的研究。

[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中国移动互联网蓝皮书. [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

本文著录格式：万文凯，汪海涛，姜瑛. 移动网络中重传超时问题的研究[J]. 软件，2017，38（12）：29-36

国家自然科学基金(61462049)

万文凯(1992-)，男，硕士，主要研究方向：数据中心网络。

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