RFC2757-Long Thin Networks-chifire自译本(5)

 

 

 

 

4.8 活动队列管理（Active Queue Management）

      

       前面已经提过，TCP回应拥塞的方式是关闭窗口并调用慢启动。延迟时间长的网络在从此状况中恢复也需要特别长的时间，因此，必须在远程窄带网络（LTNs）中避免拥塞的产生。为此，活动队列管理技术做为整个Internet上路由器的性能增强建议[RED]。此类配置机制的主要方式是通过控制路由器处的平均队列尺寸来防止‘拥塞崩溃’（congestion collapse）。当此平均队列的长度增加，随机性早期检测（Random Early Detection [RED]）增加了丢弃坏包的机率。

 

       好处有：

 

-          减少路由器的丢包数。RED机制在严重拥塞产生前，会主动丢弃少量包，而避免丢包数的激增。换个说法，其目的是通过在早期丢弃m个包，来避免以后丢弃n个包（m小于n）。

 

-          降低延迟。通过更小些的队列尺寸来实现，这对交互式的应用尤其重要。对于无线连接的交互式应用来说，其固有的延迟早己达到用户的容忍极限了。

 

-          避免死锁。由于路由器资源的缺乏（或相应信息包的丢失）可能会导致某个连接的吞吐被阻塞。采用了活动队列管理技术后，进来的信息包在路由器中找到相应处理缓冲区的机率也将增大。

 

活动队列管理有两部分内容：一是路由器在其资源耗尽前对拥塞的检测；二是提供一些拥塞指示的形式。通过RED检测而丢弃的包只是后者的一个例子。其它指示拥塞的方式是使用ECN[ECN]，如上面所述“通过显式通知方式来检测坏包丢失”。

      

       建议：当前RED已经在Internet上使用，LTN也应当遵照执行。ECN配置应当补足RED的不足。

 

4.9 时序算法（Scheduling Algorithms）

 

       活动队列管理有助于控制队列的长度。而且，通用的解决方案需要用其它的调度算法来替代FIFO，从而达到以下性能的提高：

 

 

 

 

Montenegro, et al.           Informational                     [Page 21]

 

 

1. 公平性（通过控制带宽来实现，即不同类型的信息包流只能用其可用的带宽）

 

2. 吞吐量（通过提高转发方的无线通道的利用率来实现）

 

       例如，在批方式传输会话（bulk transfer sessions）与交互式应用并存情况下（如telnet或web浏览），公平性就显得尤为重要。

 

       这方面的建议有：

 

      - 公平队列（Fair Queueing，FQ） [Demers90]

 

      - 基于类的队列（Class-based Queueing，CBQ） [Floyd95]

 

       即使它们仅在无线通讯领域得以部分实现，这些建议对于无线LTN环境来说仍极具魅力，因为，当批方式TCP传输启动以后将占据全部可用带宽，从而给交互式应用的启动造成困难。

 

       在我们前面所描述的基本架构中，移动设备通常在给定时刻只能直接与一个无线连接点（即中间媒介结点）进行通讯。在一些广域网（W-WAN）中，有可能用同样的单元（cell）直接定位其它的移动设备。与每个这样的无线连接点直接通讯可能要穿越截然不同的路径，每条路径都可能表现出独特的无线连接特性。通道状态决定包调度（Channel State Dependent Packet Scheduling ，CSDP）[BBKT96]能跟踪各种各样的无线连接（由目标设备决定）的状态，并为处于“好（good）”状态的无线连接提供优先照顾。这就避免了向“坏（bad）”的无线连接点发送或等待其回应确认，从而提高了吞吐量。

 

       有关此设想的更好建议是将CSDP [FSS98]和无线增强（wireless-enhanced）CBQ联合起来使用，从而达到同时提高公平性和吞吐量的目的。

 

       建议：目前尚无建议，还需进一步研究。

 

4.10 分割TCP及性能增强代理（Split TCP and Performance-Enhancing Proxies (PEPs)）

 

       可以用比较生动的方式来比较无线连接和有线连接的不同，一个非常通用的办法是在两种不同技术都涉及的环节，即中间介质节点处施加一些阻抗匹配。

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 22]

 

 

       这种想法是用两种截然不同的连接来替代端对端（end-to-end）TCP连接：一种是穿越无线连接，另一种是穿越其对应的有线部分。这两种方法都可使TCP会话工作在非常不同的网络特性中，可根据介质的特殊要求来选择最适合的策略。例如，在特殊的LTN拓扑情况下，通过修改TCP快中继（Fast Retransmit）使其在收到第一个重复确认后就重发；通过修改快恢复（Fast Recovery）使其在LTN连接的RTT特别长时不缩小拥塞窗口，要达此目的，较理想的方法是不对信息包进行记录，从而避免了拥塞。此外，在长延迟的连接或连接采用相对带宽延迟较高的乘积，可能采用带有相对大些初始化窗口的“慢启动”方式会好些，这些大窗口甚至要超过四个段。这几种形式的TCP改进要应用到LTN连接上，还需要进行商讨，但它们不可以用来配置整个Internet的端对端连接。在LTN拓扑中，由于连接的根本特性已经很清楚了，所以可以在不危及全球Internet操作的前提下，采用各种类似的性能增强方案。

 

       在一些建议中，除了中间介质节点处的PEP机制外，还有些约定俗成的协议，如[WAP]、[YB94]、[MOWGLI]等。

 

       即使可以通过使用非TCP协议方式来得到同样或者更好的特性，无线TCP优化研究的价值及与Internet的兼容性仍是在无线连接上采用TCP连接的主要原因（增强的建议见下面第五节）。

 

4.10.1 分割TCP的方式（Split TCP Approaches）

 

       分割TCP （Split-TCP）建议包括I-TCP [ITCP]和MTCP [YB94]等方案，它们通过丢弃端对端语法来得到性能上的提高。

 

       Mowgli体系[MOWGLI]建议在所有的协议层中都提供对分割方法的增强支持，而不仅仅是传输层。Mowgli提供了一个选项，可用一个定制好的、专门针对LTN连接的协议[KRLKA97]来替换原LTN连接中的TCP/IP内核协议。另外，该协议还为LTN网络提供了许多有用的特性，例如，它提供了基于优先级并发连接及共享流控制的多路技术，即使在有影响带宽的后台传输的情况下，仍可为交互式应用的及时性提供连接容量保证。同样，在此选项下，Mowgli保留了移动设备上的Socket语法，这样原有的应用可以不加修改地继续得以运行。

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 23]

 

 

       分割TCP的方法也有其优缺点。与其相关的优点有：

 

-          将端对端TCP连接分割成两部分，从而无线连接中的问题不会与有线的Internet路径产生关联，反之亦然，因而，分割TCP方法支持采用局部解决方案来解决无线连接中局部的问题。例如，它可以自动区别与有线Internet拥塞相关的丢包和无线连接上的因传输错误而产生的丢包，就好象这些是在分隔开来的TCP连接中产生的一样。即便两个网段（有线和无线，译者注）同时产生拥塞，因其特性不相同，仍可用同样的方法来解决。此外，无线连接中的临时性断线可与有线Internet实现有效隔离。

 

-          当一个TCP连接只是穿越单级或非常有限的几级无线连接时，无线TCP路径的全部或部分连接特性是可以知道的。例如，对于一个指定的连接来说，我们可能知道该连接能提供可靠的包传输能力，且信息包的次序不会乱，该连接也不会受拥塞困扰。有了这些与TCP通道相关的信息之后，要定义TCP减肥（TCP mitigations）方案就成了一件再轻松不过的任务。另外，有几种不能安全用于全球Internet上的减肥方案，却可成功应用于无线连接。

 

-          将一个TCP连接分成两个独立的部分之后，可以将许多最近提出的、有关提高无线连接中TCP性能的建议提早应用起来；因为只需要修改移动设备及中间介质节点的TCP实现，所以目前的为数众多的Internet主机仍可以继续运行传统的TCP实现，而不必做任何修改。任何需要修改有线主机TCP实现的减肥（mitigation）方案，要想被推广几乎是遥不可及。

 

-          允许使用多种应用级的性能增强将会带来显著的性能提高（见4.10.2节）。

 

   分割TCP方案的缺点如下所述：

 

-          有关分割TCP方案的主要批评意见是因为它打破了TCP端对端语法，它将带来许多更为严重的问题，它将导致分割后的TCP连接屏蔽IP层安全机制的端对端应用，使基于IPSec的应用无法获得端对端的安全。

 

 

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 24]

 

 

虽然IPSec可以对两个部分独立应用，但需要中间介质节点做为第三方来维系移动设备与远程主机间的安全联系，这在许多情况之下是不好实现甚至无法接受的。这时，要实现端对端安全就需要使用传输层上的其它安全机制，如TLS [RFC2246] 或SOCKS [RFC1928]。

 

-          打破端对端语法的另一个缺点是，中间介质节点处产生的冲突（crashes）将变得无法恢复，从而导致TCP连接的中止。这该否算严重问题则要看这种冲突产生的频率了。

 

-          有许多机会可以证明，当TCP端对端语法被打破以后，依赖TCP提供可靠数据传递的应用将更易受攻击。有关“设计良好的应用永远也不应完全依赖TCP来保证其应用级上的端对端可靠性”的说法只是夸大其辞。首先，当前TCP的APIs，殊如Berkeley Socket接口，应用程序无法得知前次发送用户数据的收到确认何时传给TCP发送方；其次，即使应用程序得到TCP确认，发送方应用程序仍无法得知接收程序是否确实收到了数据：它只知道数据已经到达了TCP接收端的接收缓冲区；最后，要获得应用级的端对端可靠性，要求应用级确认能确保接收端已经对其收到的数据做了相应的动作。

 

-          当移动设备发生移动时，它服从于其服务基站间的移交（handovers）。如果基站做为分割TCP连接的中间节点，前一个中间节点两端的TCP状态也必须被传递到新中间节点处，用以确认本次分割TCP连接操作的连续性。这需要做些额外的工作，并可引发超载。然而，对绝大多数的宽带广域网（W-WAN）来说，不象宽带局域网（W-LAN），W-WAN基站并不提供移动设备与有线Internet间的连接点（这类基站可能连IP堆栈都没有）。做为替代，当移动设备发生移动时，W-WAN要维护这种机动性，并使移动设备与有线Internet的连接点保持不变。因而，在多数W-WAN中，TCP状态的移交并不是必要的。

 

-          信息包穿越传输层之上的所有协议层又下到链路层，这将导致中间节点处产生额外负载。在低带宽的LTN网络中，这种超载可不象高带宽的W-WAN那样不会引发严重的性能问题（就是有可能引发性能问题，译者注）。

 

 

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 25]