Internet thin-stream 交互式应用 TCP延迟

Internetthin-stream 交互式应用 休闲 TCP延迟

  1. thin-stream的特征
 
  在大量使用可靠传输协议的Internet服务中，表现出thin-stream特征。如果一个stream满足以下1个条件则称为thin stream:
  (1) 报文interarrival time（IAT）太高无法触发快速重传;
  (2) 报文size通常远低于maximum segment size (MSS)。
 
  由于许多thin-stream应用程序（例如在线游戏、控制系统或一些传感器网络）有着很强的交互性，它们依赖性于数据的及时传送（time-dependency）。用户体验依赖于数据传送的延迟，报文的丢失使服务质量大大下降。

2. TCP的缺陷

  TCP的设计是source要求有大量的带宽用于传送报文（greedy source），大量研发工作是在有拥塞控制条件下增加throughout。TCP中在flow-control以及拥塞控制允许的条件下，sender总是尽可能快地发送数据。

  对大量的交互式应用在分析表明，使用可靠传输协议（TCP或Stream Control Transmission Protocol——SCTP）的这些应用中，由于通常的拥塞控制和恢复机制极不容易触发，因而这种stream永远不会填充允许的发送窗口。说得更具体一些，各种TCP实现中假定greedy source并不适用于thin-stream，TCP重传机制对于thin-stream也不能有效地发挥作用。
 
  对于表现出thin-stream特征的服务，当报文丢失时通常是通过TCP超时重传机制恢复，这样数据传送会出现非常大的延迟。原因如下:TCP中的快速重传机制是在某个超时之前重传丢失的segments, 这依赖于来自receiver的反馈（ACKs）。为了初始化快速重传，该机制需要three duplicate ACKs（dupACKs），需要一直等到丢失报文的第3个ACks的原因是为了避免当网络上开始reodering时存在虚假重传。对于 thin stream, 报文之间发送的IAT时间相对要高，结果是许多（甚至所有）重传是由于超时产生。这是由于存在非常少的in flight报文(packets . the wire)来生成必要的反馈，因而无法触发快速重传. 而且，当出现多次丢失时重传超时(RTO)为指数增长，即exponential backoff，这将产生更大的延迟。
 
  快速重传机制的设计目标是确保找到一个可接受的发送速率，并阻止stream对应当公平共享的带宽资源过分占用。但是Thin streams对带宽资源并没有用到公平共享，多数时间内一直为最坏情况下的throughput，每个round trip time (RTT)才有2个报文. IATs很大使得当报文多次丢失时，thin stream不可能back off, 这样就出现RTO值很高，考虑网络资源的分配没有任何实际好处。因而对于thin stream的结果就是，如果segments丢失多次则重传延迟可能达到秒级甚至分钟级.

3. TCP的增强 
  为了在报文丢失时减少应用层的延迟，修改了Linux内核中的TCP重传机制，另外为了测试报文丢失效果，还加入了一些人为引入延迟的机制。
 
  如果内核检验到出现thin stream, 则采取以下方法减少延迟：

  (1) 去掉指数回退
      因为大多数thin streams以很高的IAT发出报文，因而几乎所有的重传是由超时导致。超时重传触发指数回退，即下次重传要等待的时间翻倍。如果in flight报文数(即未应答的报文数)低于触发快速重传所需要的数目，则去掉指数因子。如果网络上的报文数超过4个，则触发快速重传的可能性增大，因而将使用通常的指数回退。该修改受益的流是think-stream，因而去掉指数回退而使带宽消耗增大的量将非常小，即thin-stream仍然不必使用其允许的发送窗口。

  (2) FASTER快速重传
     为了在超时重传时不用等待数百毫秒进行指数回退，就期望触发快速重传。这就要求连接等待three duplicate ACKs(即同一个报文有4次ACKs), 而这对于许多thin streams并不适用。这是由于在这些环境中IAT很高，发送3个报文的时间往往比超时还长。因而当in flight报文数小于4时，我们可以将所需要的duplicate ACKs数减少为1. 否则收到three dupACKs的概率增加，那么就使用通常的(three dupACKs)快速重传。
    
  (3) Redundant Data Bundling（RDB）:
      许多thin-stream应用发送的报文size很小. 因而，如果组合的报文size小于MSS, 则将发送/重传对列中未应答报文中的数据拷贝（bundle）到下一个发送的报文中。这样丢失的payload将在下一个报文中被发送的概率增大. 注意：序列号不变而报文长度增加。假定发送seq为100的报文a丢失，则下一个发送的报文中seq仍然为100, 可以将报文a和b bundle为一个大的报文。如果报文a丢失，则报文b的ACK将对a和b segments进行应答，这样就避免了重传。
     
  该机制类似与Nagle算法中合并small user write，以及Stream Control Transmission Protocol(SCTP)中在一个pkt中可承载多个用户消息,这些都可以减少发送的pkt数量。        

  只有检测到thin stream时才应用这些方法，这可以通过动态地定义报文size和count的门限值来实现。前两个方法只有当报文数小于4时才应用，而第3个方法RDB受限于IAT和报文size。

  在Linux kernel (2.6.23.8)中实现了这些修改，并在各种网络条件下测试了许多thin-stream应用程序(Skype, BZFlag, SSH, ...)，结果表明使用TCP的交互式应用中最大延迟和平均延迟时间都减少了，用户在交互中反馈更快。

  这些修改与所有的TCP标准兼容而且对receiver和上层应用透明（因为只需要修改sender-side的TCP代码）。这样，即使只有TCP server实现这些修改，也可以使单向延迟减少。

4. 参考资料
  [1] Latency reducing TCP modifications for thin-stream interactive applications, http://lwn.net/Articles/308919/
  [2] EVENSEN, K., PETLUND, A., GRIWODZ, C., AND HALVORSEN, P. Redundant bundling in tcp to reduce perceived latency for time-dependent thin streams. Communications Letters, IEEE 12, 4 (April 2008), 324–326, http://simula.no/research/networks/publications/Simula.ND.83
  [3] A. Petlund, K. Evensen, P. Halvorsen, and C. Griwodz, Improving application layer latency for reliable thin-stream game traffic, Netgames, Worcester, Ma. US, 2008, ed. by Mark Claypool, Association for Computing Machinery (ACM) (ISBN: 978-1-60558-132-3), http://simula.no/research/networks/publications/Simula.ND.185
  [4] STEVENS, W. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. RFC 2001(Proposed Standard), Jan. 1997. Obsoleted by RFC 2581.

  [5] GRIWODZ, C., AND HALVORSEN, P. The fun of using TCP for an MMORPG. In International Workshop . Network and Operating System Support for Digital Audio and Video (NOSSDAV) (May 2006), ACM Press, pp. 1–7, http://simula.no/research/networks/publications/Griwodz.2006.1

转载：http://kapok.blog.51cto.com/517862/127348  感谢博主分享