摘要

网络拥塞是互联网上普遍存在的问题，现代基于丢失的TCP算法旨在通过使用积极的拥塞窗口(CWND)控制策略来增加吞吐量，因为这种策略，导致大量数据包可能被积压，并最终在无线接入网络的入口点被丢弃，我们之前的工作提出了基于立方体的Android终端CWND控件中间件来解决积压问题，它利用往返时间(RTT)作为WLAN接入点处(AP) TCP ACK的积压状况的指示，并控制其CWND大小的上限和下限，以抑制其自身TCP数据分组的过度传输。然而，由于每个节点的中间件在开始控制时的时间差，中间件导致了严重的公平性下降。在这项研究中，我们提出了一种新的机制，它考虑了传输的公平性。我们的新方法从考虑协同性开始控制，评估表明，通过了解网络中所有其他竞争设备的情况，我们的新方法比以前的方法获得了更多的协同性和公平性。

关键词

TCP，拥塞控制，RTT，Android，吞吐量，公平性

1 介绍

随着智能设备(如智能手机和平板电脑)技术的进步和网络带宽的增加，基于损耗的TCP也得到了改善，特别是现代基于损失的TCP，如BIC[17] 和立方[6] 使用积极的CWND控制策略，以获得优于其他竞争TCP会话的吞吐量。由于这种策略，大量的分组可能被积压并最终在无线网络的入口点被丢弃接入网络，因为无线链路提供的带宽通常比有线回程和主干网络窄得多。当终端通过WLAN连接时，此缺陷不仅适用于下行TCP段，也适用于上行TCP段，这不考虑CSMA/CA[11] 基于调度。此外，来自连接WLAN的手持设备的移动流量正以前所未有的速度增长，这设备激增进一步加剧了ACK分组积压问题。

在我们之前的研究中，开发了用于Android终端的基于立方的CWND控制中间件来解决上游TCP会话的问题。它利用往返时间(RTT)作为WLAN接入点(AP)处TCP ACK积压情况的指示，并控制其CWND大小的上限和下限，以抑制其自身TCP数据分组的过度传输。中间件通过避免AP上的ACK分组累积来提高总吞吐量。在我们之前的工作中，我们使用运行Android OS版本4.1 (Jelly Beans)的Nexus S手机作为客户端终端来评估中间件。

我们研究中，由操作系统版本为6.0.0 (Marshmallow)的Nexus 7平板电脑和操作系统版本为5.1.1(Lollipop)的Nexus 5智能手机以及Nexus S组成的系统上对该方法进行了评估。评估表明，通过该方法，所有类型的设备上的aggregate吞吐量均有所提高，从而避免了AP上的ACK数据包累积。

在研究中，我们引入了一种新的机制，它考虑了传输的公平性。在之前的方法中，当每个设备中的中间件检测到其自身的RTT值显著增加时，该中间件开始独立地控制CWND大小。所有终端的RTT值有时可能同时显著增加，并且所有终端的中间件几乎同时开始控制CWND大小。如果是这种情况，前面的方法是有效的。然而，我们发现很有可能不是所有的客户端都通过先前的机制开始它们自己的CWND控制，因为每个设备仅通过检测它自己的RTT值的增加来开始控制CWND大小。在一些终端控制它们的CWND并解决积压问题的情况下，其他终端不控制并获得显著更高的吞吐量。这意味着同一网络中的客户端不能平等地共享带宽。关键是在同一个网络中存在受控设备和非受控设备。以前的中间件提高了总吞吐量，因为只有一部分设备占用带宽并获得高吞吐量，而公平性显著降低，因为其他客户端只能使用少量带宽。一般来说，当只试图提高吞吐量时，会出现公平性下降的现象。

在本论文中，我们评估并提出了一种考虑传输公平性的新机制。具体来说，我们展示了中间件决定如何开始控制所导致的严重错误。当检测到至少一个客户端的RTT显著增加时，我们新提出的机制开始控制连接到同一AP的所有终端的CWND大小。因此，通过考虑控制开始条件的协作性，我们试图提高客户端之间的公平性。通过理解网络中所有其他竞争设备的情况，我们的方法比以前的方法获得了更多的合作性和公平性。然后，我们展示了该方法在不同终端Nexus 5和Nexus 7上的有效性。

图1:CDUBIC-TCP的行为

2 背景

2.1安卓操作系统

这项研究的重点是实现我们提出的机制作为Android平台的中间件。Android操作系统是一个移动终端平台，由谷歌开发，并作为一个包分发，包括操作系统、中间件和一组应用程序。Android的源代码可通过开放手机联盟的Android开源项目获得。因此，我们可以将我们提出的方法应用于任何其他Android终端，只需稍加修改即可。

请注意，Android是基于Linux内核构建的，它提供了多堆栈网络、多任务、虚拟内存管理和虚拟机等基本功能。因此，这项工作可以应用于任何其他基于Linux的终端或系统，尽管性能评估只在Android终端上进行。

由于Linux中默认的TCP版本是CUBIC，所以Android采用了CUBIC作为传输协议。与许多其他传输协议一样，CUBIC基于CWND控制数据包传输速率，CWND是数据包接收器未收到ACK数据包时可以传输的最大数据包数量。设置合适的CWND是实现高吞吐量的关键，这是TCP版本之间的主要区别。

图1，在我们的实验系统中，显示了CUBIC的行为。CWND大小通过表达式计算收到ACK后，CWND逐渐增加，每次出现丢包时，CWND减半。由于CWND的大小会随着数据包的丢失而减小，因此它被称为基于丢失的TCP。立方也有一个独特的功能，改变其CWND与通道这在其他基于丢失的TCP中是看不到的。此外，基于延迟的TCP 根据RTT减少CWND大小(例如TCP Vegas、TCP Westwood)。

图2:内核监控工具概述

图3:中间件概述

2.2 内核监控工具

内核监控工具是一个系统工具，它可以观察 Linux 内核代码内部的参数行为，这通常是观察不到的。我们之前的工作成功地将其嵌入到 Android 平台中，以便实时分析移动主机的连接状态。如图2所示，它允许用户监控移动主机上内核处理的参数，包括 CWND、RTT 和错误计时。

 2.3 CWND 控制中间件

本小节描述 CWND 控制中间件(图 3)在我们之前实现的工作[8][7]。这个中间件是基于内核监控工具开发的，因此它可以访问内核内存空间中参数的当前值。当 Android 终端通过 WLAN 连接到服务器并且检测到拥塞时，它控制 CWND 大小。

当共享同一个 AP 的其它终端开始通信，RTT 值显著增加,基于 AP 和中的积压长度的 CWND 大小的下限使用 proc 接口的通信终端数量。

图 4:之前实现的中间件的流程图

中间件的流程图如图4所示，拟建系统的工艺流程如下：

(1) 如果在 TCP 通信期间检测到 RTT 值大幅增加，则开始控制 CWND 大小。

(2) 计算 CWND 大小上限和下限的理想极限。

(a) 使用 proc 接口的终端数量是通过向连接到同一 AP的每个终端广播用户数据报协议(UDP)包来统计的。

(b) 上限大小(MAX CWND 1)的第一候选根据表达式基于终端的数量来设置2。

(c) 从内核监控工具获取当前 RTT 值。

(d) 基于所获得的 RTT 值计算 AP 中积压工作的估计长度。

(e) 上限大小的第二候选值(最大 CWND 2)根据表中的 RTT值进行设置1.

(3) 比较最大 CWND 1 和最大 CWND 2，选择较小的一个作为CWND 的理想上限大小(理想最大 CWND)。

(4) 应用理想最大 CWND 作为 CWND 大小的理想上限。

(5) 重复从(2)到(4)的过程，每隔 0.5 秒调整一次。

CWND 调整方法

使用这种方法，控制系统可以限制流量爆发的数量。我们没有在中间件中修改拥塞控制算法本身，因此基本的 TCP 功能可以保持互操作性。然而，已经通过设置 CWND 的上限和下限的水平来优化通信，并且基于 AP 周围的通信状况来调整拥塞控制。我们之前的工作使用 Android Nexus S 智能手机作为客户端。由于 Android 在功能或固件方面仍在大幅改进和升级，我们推出了新型号和操作系统版本的 Android 设备，如 Nexus5 智能手机和 Nexus 7 平板电脑(见表2).在本文中，我们提出了一种考虑公平性的新方法，这种方法在不同终端上是有效的。

表2:设备规格

3 基本测试

在有线网络的情况下，TCP最初假设分组丢弃是网络拥塞的指示，因为分组被丢弃的主要原因是沿着到另一通信对等体的路径的路由器之一处的队列溢出。然而，无线通信引入了分组丢失的其他原因，例如弱化、冲突和干扰，这混淆了TCP CWND控制算法并导致次优性能。无线通信对TCP性能的影响解决这些问题的技术已经得到了广泛的研究在文献中。

我们以前的工作表明，当同一接入点周围的终端数量增加时，总吞吐量会迅速下降。这是因为AP中可能发生缓冲区溢出，AP开始丢弃数据包。

在本节中，我们创建了一个基本测试来证明这一现象。我们使用实验系统评估了WLAN网络中的设备性能，如图5所示。客户终端通过802.11g网络连接到AP，AP通过有线路由连接到服务器主机。作为客户端，我们使用了Nexus 5智能手机和Nexus 7平板电脑。终端的数量从1到6不等。为了模拟网络延迟和数据包丢失，一个网络仿真器Dummynet[1]被插入到AP和服务器主机之间；100毫秒延迟是通过假设高延迟环境设置的。由于千兆位以太网，有线部分的连接速率更高，而在无线环境中，带宽只有大约20Mbps。作为网络基准测试工具，Iperf for Android 安装在所有的终端上。实验中使用的每个设备的规格如表2所示。

 图5:实验拓扑

图6 表示终端数量和总吞吐量之间的关系。

红色和蓝色线条分别显示了Nexus 5智能手机和Nexus 7平板电脑的结果。如两条线所示，当终端数量接近3并且AP变得过载时，吞吐量开始下降。AP和终端之间的无线传输部分是瓶颈，严重限制了整体吞吐量。为了解决这个问题提出了开发中间件。 

4 先前实施的性能评估

4.1实验概述

为了评估在之前的研究中开发的中间件，我们将它安装在智能手机(Nexus 5)和平板电脑(Nexus 7)上。使用与图1相同的实验拓扑5，我们观察了终端的行为，并评估了之前实现的中间件的效果。终端的数量从3到6不等。

4.2实验结果

图7分别显示了在Nexus 5智能手机和Nexus 7平板电脑上观察到的终端数量和总吞吐量之间的关系。浅蓝色条(默认)显示没有中间件时的结果，浅蓝色条(旧)显示运行之前提出的中间件时的结果。

如图所示7，当3到5部Nexus 5智能手机连接到同一个AP并同时进行通信时，中间件的效果适得其反。虽然中间件使6个终端通信时的总吞吐量稍微高了一点，但它仍然比没有中间件的3个和4个终端通信的值低得多。这意味着以前的中间件没有解决当同一AP周围的终端数量增加时出现的吞吐量下降现象。

相比之下，中间件提高了Nexus 7平板电脑在任意数量的设备上通信的吞吐量。接下来，我们使用公平性指数以确认可用带宽被公平地分配给每个终端。公平性指数指示公平性，并且计算值对应于最高公平性。

图7终端数量和总吞吐量之间的关系

图8分别显示了在Nexus 5智能手机和Nexus 7平板电脑上观察到的终端数量和公平性之间的关系。浅粉色条(默认)显示没有中间件时的结果，亮红色条(旧)显示运行之前实现的中间件时的结果。如图所示8在4台Nexus 5手机和5台Nexus 5手机通信时，通过中间件提高了公平性。然而，当5个终端与该机制通信时，与的结果相比，公平性不够高。3和4个终端，在Nexus 7上也可以观察到类似的结果。此外，Nexus 5和Nexus 7的两个结果的共同点是，当6个终端通信时，尤其是当之前实现的中间件正在运行时，公平性相当低。换句话说，中间件不仅对吞吐量有负面影响，而且对公平性也有负面影响。

图8:终端数量和公平性之间的关系

5 拟议机制

5.1之前实施的问题

如小节所述2.3当其自身终端的RTT值显著增加时，该机制开始控制CWND大小。如图9所示只有一部分终端设备(节点1 - 5)受到严格控制，而其他设备(节点6)不受控制并占用带宽。因此，一个问题(以下称为问题1)是在同一网络中存在受控和非受控设备的可能性，因为中间件仅在检测到其自身的RTT值增加时才评估开始控制CWND大小的定时。结果，我们发现这个问题导致了公平性的下降。此外，如图10所示由中间件控制的CWND大小相当小。这意味着带宽仍然可以使用，因为控制的严格程度。这可能是导致低总吞吐量的第二个问题(以下称为问题2)。

5.2机制改进的细节

为了解决以前的中间件存在的问题，我们对该方法进行了改进，以考虑公平性。首先，为了防止问题1，我们改变了当系统tem开始控制CWND尺寸。图13显示了系统改进后的流程图。修改的部分是步骤2 (S2)和步骤3 (S3)。在先前的方法中，终端安装中间件，当它检测到它自己的RTT值显著增加时，开始控制它自己。相比之下，所提出的机制在检测到AP周围的终端中至少有一个显著的RTT增加时，开始控制连接到同一AP的所有终端的CWND大小。通过协调控制开始条件，我们试图提高客户之间的公平性。我们称这种方法为建议机制1。为了收集同一网络中所有终端的RTT值，终端通过UDP广播它们自己的RTT信息。

最重要的是，我们改进了中间件来解决问题2。如表1所示，在分段中2.3中间件根据RTT差值控制CWND的大小。由于该表参数可能过于严格，我们将这些参数做得更大，以便与所有客户端高效地共享带宽。表中显示了更新的参数3。我们称之为修正的建议机制2。

图9:由先前机制控制的CWND的行为(Nexus 7平板电脑)

图10:由先前机制控制的CWND的行为(Nexus 5智能手机)

图11:由提议的机制1控制的CWND的行为(Nexus 5智能手机)

图12:由提议的机制2控制的CWND的行为(Nexus 5智能手机)

使用建议的机制1和2，我们再次在如图所示的相同环境拓扑下执行测试5.

表3 CWND调整方法

图13:提议的中间件的流程图 

5.3对拟议机制的绩效评估

5.3.1提议机制的行为

图11和图12显示出了分别由所提出的方法1和2控制的CWND大小的转变。如图所示，因为控制开始定时是同步的，所以带宽在客户端之间被公平地共享。请注意，由于RTT值通知是由UDP广播的，因此每个控制开始时间之间会有一点差异。另外，CWND的尺寸图12比图11 中的大(有些行达到300行)经过建议方法2的手段。虽然跳过了Nexus 7的结果，但这样的有效性也在表格上表现出来了。

5.3.2吞吐量和公平性之间的相关性

正如我们之前提到的，我们方法的重要特征是在不降低总吞吐量的情况下提高公平性。为了对其进行评估，我们将Nexus 5和Nexus 7的总吞吐量和公平性值显示为图中的散点图14和15分别是纵轴显示公平性，横轴显示总吞吐量。红色、蓝色、绿色和橙色标记分别表示3、4、5和6个终端同时通信的结果。我们在与图1所示相同的环境中进行了测试5 没有任何中间件(以下称为默认)，具有先前实现的系统(以下称为旧的)，具有提议的机制1(以下称为NEW1)和提议的机制2(以下称为NEW2)。

如图14所示，NEW1和NEW2达到比默认和旧的更高的吞吐量和公平性。相反，旧值的结果是任何数量的终端的吞吐量都很低。例如，使用先前实现的中间件获得的4个终端通信的点达到相当高的公平性，因为所有终端的CWND被控制在几乎相同的值。然而，总吞吐量非常低，因为给予每个设备的受控CWND大小太小结果带宽还没用完。这一问题已通过改变小节中提到的参数得到解决。

5.2另一个例子是在图的左下方出现了5个和6个终端的故障点。换句话说，当许多(5或6个)终端同时通信时，公平性和吞吐量都会降低。以前实现的中间件不能提高这些值，而我们的中间件(NEW1和2)成功地使这两个值显著提高，如图14右上方所示。

如图15所示，NEW1和NEW2在Nexus 7平板电脑上达到了比默认和旧版本更高的吞吐量和公平性。此外，当许多(5或6个)终端在默认模式下通信时，公平性和吞吐量都会下降，这也是Nexus 7上的问题。虽然旧的中间件提高了六个终端通信的吞吐量，但是由于同一网络中受控设备和非受控设备的存在，公平性非常低。一些终端，之前的中间件没有运行，继续默认传输，占用了太多的带宽。NEW1通过改变控制开始条件解决了这个问题，如5.2小节所述。然而，由于当六个终端通信时，NEW2的公平性变得比NEW1差，我们需要考虑小节中提到的参数2.3再进一步。

图14:默认传输、之前实现的中间件、提议的机制1和2实现的Nexus 5的总吞吐量和公平性的散点图。纵轴显示公平性，横轴显示总吞吐量。

图15:默认传输、之前实现的中间件、提议的机制1和2实现的Nexus 7的总吞吐量和公平性的散点图。纵轴显示公平性，横轴显示总吞吐量。

6 结论

本研究针对上行TCP会话的ACK包积压问题，提出了基于立方的CWND控制中间件，兼顾了吞吐量和公平性,它控制其CWND大小的上限和下限，以抑制其自身TCP数据包的过度传输。我们在Nexus5和Nexus7异构终端上安装了中间件。通过使控制开始条件考虑合作性，我们试图改善客户端之间的公平性。结果，所提出的中间件产生了相当高的公平性和吞吐量。通过理解网络中所有其他竞争设备的情况，我们的方法比以前的方法获得了更多的合作性和公平性。我们将在混合使用Nexus 5和Nexus 7设备的环境中进行更多测试。

---煤油灯科技victorlamp.com翻译整理---