Inferring TCP Connection Characteristics Through P

被动测量推断TCP连接特性SharadJaiswal,GianlucaIannacconeChristopheDiot,JimKurose,DonTowsleComputerScienceDepartmentUniv.ofMassachusetts,Amherst{sharad,kurose,towsley}@cs.umass.eduIntelResearchCambridge,UK{gianluca.iannaccone,christophe.diot}@intel.com摘要----我们提出了一种被动的测量方法，它能够追踪TCP连接时的两个重要变量的值：发送方的拥塞窗口（cwnd）和连接往返时间(RTT)。这两个变量一起提供了一个极有用的诊断性终端用户感知网络性能。我们的方法是通过模拟和并发主动测量来得到验证的，并被证明是能够处理各种类型的TCP算法。鉴于我们的被动方法和测量点由Tier-1网络提供商采用，我们将能够分析10万条以上的连接量，并且发送方占有量将超过现今互联网的自治系统的45％。我们的结果显示：（1）发送方的吞吐量往往受限于要发送的数据的匮乏；（2）TCP拥塞控制协议往往对吞吐量影响很小；（3）绝大多数连接的RRT在其生命周期内并没有什么大的变化。关键词----网络测量，拥塞分析，TCPI.（前言）TCP（传输控制协议）是互联网上最主要的端到端传输协议，拥有非常广泛的应用，例如：web流量，电网应用，和一些新兴的依赖于TCP传输服务的p2p应用等。鉴于对TCP协议的依赖，目前有极大的兴趣想要了解TCP的运行、并描绘出在实践中能限制其行为的因素（比如说：网络拥塞、接收方/发送方的缓存极限、发送方的数据匮乏）。在这篇文章中，我们将呈现一种被动的测量方法，它将对一个TCP连接（无论是“从发送方到接收方”还是“从接收方到发送方”）上的数据包进行观察，并推断/跟踪拥塞窗口（cwnd）、连接往返时间(RTT)这两个重要变量的值的变化。根据这两个变量的值，我们就能确定许多重要的参数，如发送方、接收方以及连接它们的网络路径等。例如：（1）通过将拥塞窗口（cwnd）与实际发送的数据量相比，就可以判断出TCP连接何时开始传输应用层的数据（换言之，如果有大量的数据，则表示连接可以支持较大的传输速率）；（2）通过认真地观察拥塞窗口（cwnd）对丢包事件做出的变化，我们就能找出不合格的TCP发送方，或者特别适用的TCP算法（如Tahoe,Reno,NewReno）；（3）通过对往返时间(RTT)的监控，我们能够描绘出RTT在flow（流）当中的变化趋势，并确定应用级程序对可变网络延迟的自适应性程度。我们的工作做出了以下几项重要的贡献：我们的第一个贡献是一套方法。我们研究出一种被动的方法：即通过对TCP数据包通过一个测量点时的观察来推断发送方的拥塞窗口（cwnd）。这个测量点可以在发送方与接收方之间的任意一个地方。我们唯一的要求是，TCP连接的两个方向上都能观察到包，这个要求在我们以前的工作[11]中已经被证明了是一个不太严格的要求。在我们的这套方法中，以防连接中断，我们会根据TCP拥塞控制算法（Tahoe,Reno,orNewReno）来对拥塞窗口（cwnd）做出判断，这时的拥塞控制算法是与发送方当前被观察到的行为最相符合的。基于拥塞窗口（cwnd）的估算，我们还提出一个简单的RTT估算方法。我们的第二个贡献是在的测量方面，以及对在SprintIP骨干网内收集的痕迹的应用。我们将给出被观察到的TCP连接的拥塞窗口(cwnd)和往返时间（RTT）的分布情况。我们的研究在对非常大量并且多样化的TCP连接的观察是唯一的。鉴于我们的被动方法和测量点由Tier-1网络提供商采用，我们将能够分析10万条以上的连接量，并且发送方占有量将超过现今互联网的自治系统的45％。我们发现：（1）发送者的吞吐量往往受限于要发送数据的缺乏，而不是网络拥塞；（2）大多数的TCP连接在报文段个数达到10时其拥塞窗口(cwnd)就达到最大值了，但是50%到60%的属于这个连接的数据包都有一个大于10个报文段的窗口；（3）绝大多数连接的RRT值在其生命周期内并没有什么大的变化。例如：约80-85％的连接，其RRT值的第95百分位与第5百分位的比值小于3；就绝对数字而言，约75-80％连接，其RTT值在连接的生命周期内的变化小于1秒。（4）最后，大多数TCP拥塞控制算法对发送方的吞吐量只有很小的影响；绝大多数的连接在不依赖于拥塞控制算法时也能达到相同的吞吐量。本文的其余部分安排如下：第二部分（SectionII）将讨论相关的工作。在第三部分和第四部分（SectionIIIandIV）我们将呈现我们的算法：跟踪发送方的拥塞窗口、推断发送方的TCP算法、并计算RTT。在第五部分（SectionIIV）我们将确定那些能引起我们的估计的不准确的事件，并定义这些不准确的边界。第六部分（SectionVI）通过模拟和真实世界的实践来介绍我们的方法的评估结果。第七部分（SectionVII）介绍我们的观察结果，该结果是通过对SprintIP上的骨干网络上大量的核心测量点上的数据包的痕迹进行观察和分析而得到的。最后，第八部分（SectionVIII）总结我们的贡献，并为这项工作的延伸提供方向。II．相关工作许多测量研究已经对互联网上的TCP连接的特性进行了探讨。早期许多的研究[17]要么是主动地测量端到端的TCP连接的属性（例如，丢包，延迟，吞吐量），要么是被动地描绘连接的总属性（如大小，持续时间，吞吐量）[20]。最近，研究人员都集中对TCP实现的具体细节感起了兴趣，[15]开发了一个工具来描述远程Web服务器上的TCP行为。他们的做法是主动地将请求发送到Web服务器上，并逐步地减少选择响应数据包，以便观察服务器对中断的响应。他们观察各种TCP的普遍实现、TCP选项的存在，如SACK和ECN，并确定符合/不符合拥塞控制行为。相比之下，我们的做法是被动的，因此能够很容易地描绘出大量的TCP连接。[16]中，作者在一系列终端主机上运行tcpdump命令。那文介绍了一个分析这些痕迹的工具----tcpanaly，并对8种不同类型的TCP实现过程的差异进行了分析。在理论上我们的工作很相似，有些方面上，我们都涉及到了被动地观察TCP连接的行为，并用这种方法来决定哪种算法或者TCP实现与我们所观察到的TCP连接是最相符合的。但是[16]主要还是集中在突出各种TCP实现栈之间的差异。由于我们的测量点是在端到端路径的中间位置，所以我们很难区分一个发送方的特殊行为是由网络事件引起的还是终端系统的TCP实现事件引起的。此外，由于我们跟踪上百万条高度多样化的TCP连接，我们并不考虑发送方的实施细节。我们的主要目标是跟踪发送方的拥塞窗口（cwnd）。我们只企图去发现我们对拥塞窗口（cwnd）的估计可能与发送方的不同时的情况，并不会对这些不同做出非常详细地分析。此外，在[16]，分析的痕迹中涉及大量的文件传输，因此作者没有考虑发送者和应用程序的行为的影响。但是我们的论文中却对这一方面作了些详细讨论。[16]中在讨论观察点的位置时，还谈到了估算连接的RTT（相对于在终端主机上的测量）时方法上的困难，但是我们会在本论文中对这个问题提出了一个解决方法。最后，我们的研究规模更大和更多样化。另一篇相关的论文是[11]，在与我们目前的工作环境几乎相同的情况下，它提出了一种对失序的数据包进行分类的方法。在本文的第四部分中，我们将使用[11]中的这种方法来确定跟踪中的哪些数据包应该被重传。[21]或许是与我们的工作最密切相关的。[21]中，作者被动地监测TCP连接，并提出了一种根据限制吞吐量的因素来对TCP连接进行分类的方法。当然也提出了一种估算RTT值的方法：即从预先设定好的一组值当中选出一个与当前所观察到的数据包的阶梯变化最相符合的值。我们的工作与[21]在几个重要方面还是有些不同。最大的差别是，我们的目标不是研究TCP速率限制因素，而是更根本的提出一种估算拥塞窗口（cwnd）和往返时间（RTT）值的方法。这可以说是TCP发送方的状态的两个最重要的部分，我们将看到，这两个变量的值将有助于我们研究、了解TCP连接的许多其它属性。（1）这些值可以被用来确定限制TCP吞吐量的因素；（2）这些值也可以用来检测不符合的TCP发送方，并确定不同类型的TCP算法在实践中的使用的程度；（3）这些值也可以用来确定新版本的TCP多久能行使其增强的功能（例如，NewReno的快速恢复机制在实践中多久才会真正地被使用）。如果我们的工作与[21]相重叠（例如，确定限制TCP连接吞吐量的因素），由于[21]的方法尚未发布，请不要与其进行直接比较。我们觉得，既然[21]中技术与我们目前工作中的技术是互补的，相比于任何一种方法的单独使用，他们的结合使用将能更好地对TCP行为进行分类。最近的一些研究也考虑到了使用被动测量来估算连接的RTT值的一些问题[12][13]。他们只对每一个在三次握手或者慢启动阶段的TCP连接计算一个RTT样本值。我们将在这些工作的基础上进行延伸，估算在其生命周期内RTT值。III．跟踪拥塞窗口在这部分中，我们将描述我们的方法：跟踪一个发送方的拥塞窗口（cwnd）。拥塞窗口即发送方在任何给定时间点能传输的数据的最大值。其基本思路是对测量点所观察到每个TCP连接的发送方的状态创建一个“副本”。这个“副本”是一个有限状态机（FSM）。副本有限状态机（FSM）会根据所观察到的“接收方到发送方”的ACKs（如果在发送方收到）来更新目前发送方的cwnd的估计值，因为“接收方到发送方”的ACKs将会引起发送方的状态变化。当在发送方检测到超时事件时也会引起有限状态机（FSM）状态的变化。使用[11]中的被动测量技术检测得知，这些超时事件通常表现为“发送方到接收方”的失序数据包的重传，[10]中详细描述了有限状态机（FSM）的实施。对一个远程的发送方的状态进行估计时遇到了许多挑战：z为了处理大量的数据（即数百GB），“副本”只能执行有限的处理，并维护很少的状态。因此，我们的副本以“流”的形式工作着，它可以既不能往回跟踪，也不能修改以前的状态变化。z鉴于测量点在端到端路径的“中间”位置，“副本”观察到的数据包序列可能与发送方不同。在测量点观察到的ACKs可能到不了发送方。此外，从发送方发送的数据包可能会在“发送方到测量点”的路径中被重新排序或复制。这里，我们使用[11]中的技术来识别和分类失序数据包。z丢包后引起拥塞窗口（cwnd）改变的行为是由发送端方选择的拥塞控制算法所决定的。我们将研究TCP拥塞控制的3种主要的算法-Tahoe,RenoandNewReno1，并为每种算法画出一个有限状态机。zTCP发送方的实施细节，以及TCP选项的使用，对于“副本”是不可见的。上述所有的考虑都将引起拥塞窗口（cwnd）的估计的不准确性，我们将在第五部分进行更详细地讨论。有几个变量在副本有限状态机（FSM）中必须初始化。发送方的初始拥塞窗口，icwnd，即发送方在完成三次握手后、任何的ACKs到达之前可以传输的最大字节数。icwnd的值可高达最大报文段大小的两倍[3]。一个实验性的TCP规范允许icwnd高达最大报文段大小的四倍[2]。在看到一个从接收方来的ACK之前，我们通过对观察到的数据包计数来估计icwnd的值。我们还初始化慢启动阈值（ssthresh）为一个非常大的值，这通常是在TCP协议栈里实现的[3]。在正常操作过程中，TCP发送方要么处于慢启动阶段，要么处于避免拥塞阶段。一个新的ACK到达时，慢启动阶段的拥塞窗口(cwnd)将变为其现值的2倍（因为其是指数增长的），避免拥塞阶段的拥塞窗口（cwnd）将加1（因为其是线性增长的）。如果发送方因超时而检测到一个包的丢失，它将拥塞窗口（cwnd）的值设为1、慢启动阈值设为max（min（awnd，cwnd）/2，2），其中awnd是接收方的通告窗口。更有趣的情况是：当通过接收到三个重复的