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

 

 

 

       应答间隔要求ACK毫发无损地穿越应答间隔路由器。当应答间隔路由器也是中介结点时，要求W-WAN环境的工作运转良好才行。

 

       在我们提出本建议之前，需要对有限字节计数（Limited byte counting）进行更深层的研究。

 

4.3.2.2 每节应答（ACK-every-segment）

 

   每节应答的主要思想是这样的：

 

-          在慢启动过程中，通过关闭延迟的ACK确认信号[RFC1122]来维持恒定的返回ACK信号流。每节应答只限于慢启动，这样可以避免不对称的带宽配置所带来的问题。例如，低带宽连接在将确认信号返回给发送方时，会阻碍堵塞窗口的形成，即使连接的客户端的带宽足够大也是一样[BPK99]。

 

接收方不必等待200毫秒以得到延迟的确认，而直接从发送方处接收未加修改的第二个段。为使该技术具有实践性，当发送方处于慢启动时，接收方必须获得每一个段。然而，当发送方处于堵塞避免状态时，如果还继续这样做，就会对移动设备的电池消耗及网络的交通状况造成负面影响。

 

       这违背了[RFC2581]所规定的原则：TCP接收方必须使用延迟的确认。

      

       “在慢启动过程中屏蔽延迟的ACK确认信号”是无法实现的技术，因为接收方无法知道发送方何时穿越慢启动门限（ssthresh,slow start threshold），何时开始使用堵塞避免算法。如果接收方遵照增长初始化窗（increased initial windows）的建议来做，在初始化窗增长时屏蔽延迟的ACK确认信号，将使TCP窗打开的更快，而且通常不会造成双倍的ACK通信量。然而，如果大多数连接维持在慢启动时状态，这种方案仍可能导致双倍的ACK通信量。

 

       建议：立即对新连接的第一个段进行应答（ACK）。

 

 

 

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 16]

 

 

4.3.3 慢启动终止（Terminating Slow Start）

 

       为了降低网络堵塞的可能性，更好地利用带宽，从而提高改善TCP的特性，又推出了一种新的机制，即[ADGGHOSSTT98]。该机制将堵塞窗的结束限制在1个段内（排除了快中继），并导致并发的慢启动重新调整相位。

 

       因此，适宜的慢启动门限(ssthresh)值将使连接尽可能地利用带宽，而不会造成‘超载’（‘overshoot’，即占用太多带宽以致产生丢包，并致使堵塞避免程序被调用）。

 

       建议：即便我们知道如何去做，也不建议对慢启动门限值进行估算。虽然这可能会有帮助，但tcp-impl和tcp-sat邮件列表的大多数人认为，在TCP启动过程中尚无可靠的方法来探测这种情况。

 

4.3.4在慢启动期间产生应答（Generating ACKs during Slow Start）

 

       通过注入附加的应答（首段应答［ACK-first-segment］或慢启动过程中的每段应答［ACK-every-segment-during-slow-start］）方式缓解只能在连接的慢启动阶段使用。在初始交换之后，连接通常会结束慢启动，TCP只有在下列情形时才会注入附加的应答：

 

（1）      连接关闭，新连接打开；

 

（2）      TCP处理因慢启动而重新启动的空闲连接。

 

其中，第一种是在HTTP/1.0上使用，针对每个请求回应事务，都需要一个新的连接。HTTP/1.1中的稳固连接有助于在堵塞避免情况下保持连接，而不是回复慢启动状态。由此，此类只能在慢启动阶段激活的优化并没有什么大的用武之地。至于第二种，很显然，与HTTP的版本无关。

 

 

4.4 应答间隔（ACK Spacing）

 

       在慢启动过程中，发送方通过为每个应答传输N+1段来回应即将到来的应答流，其中，N是即将到来的应答信号所承认的新段的序号。这将导致数据在网络上被传输两遍。相应的，也会形成队列，也会在路由器处由于缓冲不足而产生瓶颈，从而造成因连接能力不足而引起的丢包。

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 17]

 

 

 

       增大应答的间隔可以有效地控制发送方在网络上的传输速率，在瓶颈路由器处可能会形成少量排队[ACKSPACING]，此外，应答间隔还降低了短脉冲串的尺寸。

 

       建议：目前还没有建议，请继续关注此领域的研究。

 

4.5 重复应答延迟（Delayed Duplicate Acknowlegements）

 

       如上所述，大多数丢包是拥塞引起的。链路层中继可能会在很大程度上减少位错率，但对因切换网络或超出无线覆盖范围等原因引起的中断来说，还是无济于事。因为链路层和TCP层会复制彼此的功能，所以必须防止链路层和TCP层之间的中继，这样可以使TCP方面产生延迟，从而为链路层的恢复创造条件。基于这种想法，在延迟复制包（Delayed Dupacks， [MV97, Vaidya99]）方案中，在接收方有选择性地延迟重复确认。理想的方式是，让本地的机制来解决本地的问题，而不必调用TCP的端对端（end-to-end）机制，从而减少了带宽浪费等相关的代价。

      

       由于中间介质节点不需要检查TCP头，延迟复制包方案可以用于IP加密方式。

      

       通常情况，接收方拖延多长时间来重复确认是很好理解的。在特殊情况下，无线介质访问控制协议（medium access control ，MAC）在选择延迟参数时，还需要斟酌一番。MAC协议可能会影响到选择适当延迟（静态或动态）的能力。通常，在链路级中继期间发生的重要变化会给延迟复制方案的性能造成负面的影响。而且，在后续的章节（4.10.3节）中也指出，延迟复制以及其它一些方案（如侦听－Snoop,[SNOOP]）只对某种特定类型的网络连接有益。

      

       建议：延迟重复确认可能会对一些特定的网络拓扑有用，但作为一般性的建议来说，则还需进行更深一层的研究和实验。

 

4.6 选择性应答（Selective Acknowledgements） [RFC2018]

      

       按照[TCPHP]1.1节中的陈述，选择性应答（SACK）可能不太适用于许多LTN型网络。在LFN体系下，由于使用的是大窗口，而且每个窗口都会有相当大的机率丢失多个段，所以SACK就显得有用些。

 

 

 

 

Montenegro, et al.           Informational                     [Page 18]

 

 

 

在LTN体系，TCP窗口要小很多，为了破坏重复段，脉冲错误（burst errors）必须要持续更长的时间。

      

       相应的，除非无线连接上的脉冲错误（burst errors）或拥塞的机率更高，否则可能无法调整SACK的复杂性。总之，为非LTN环境提供TCP兼容性呼声将迫使LTN支持SACK。

      

       [AGS98]建议在卫星环境下使用带有大TCP窗的SACK。注意，这暗示了支持PAWS（Protection Against Wrapped Sequence space）和RTTM（Round Trip Time Measurement）。

 

       Berkeley在侦听协议（SNOOP，[SNOOP]）的研究中指出，选择性确认（SACK）在每个窗口都丢失多个段时不会提高侦听的吞吐量[BPSK96]。即使在一个往返周期内丢失多个段，SACK仍可允许侦听恢复。因此，移动设备需要实现此种类型的选择性确认。如果不使用选择性确认，TCP在拥塞避免中所耗费的时间可能会比中继的更长。

 

建议：为与其它TCP保持兼容性以及提高SNOOP的性能，应立即实现SACK。

 

4.7 侦测坏包损失（Detecting Corruption Loss）

 

4.7.1 非显式通知（Without Explicit Notification）

 

       因为无法从网络上得到明显的提示，有些研发人员建议采用统计的方法来解决拥塞避免[Jain89, WC91, VEGAS]。自然地，这些探索将有助于发送方区分因拥塞或其它原因产生的丢包。基于发送端可靠性的研究结果不是很理想[BV97, BV98]。[BV98a]在对照环境下，在接收端测量包内部到达的次数，其结果要稍好些，但是延迟因素太多，比如在无线环境中电池切换等，这些都使探索过程遭遇挫折。

 

       建议：此时尚无建议，请继续关注最新研究的结果。

 

 

 

 

 

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 19]

 

 

 

4.7.2 显式通知（With Explicit Notifications）

 

由于可从网络上得到显式的通知，可以确认丢包是否是因拥塞引起的。有如下几个建议：

      

-          显式丢包通知（Explicit Loss Notification ，ELN [BPSK96]）

 

-          显式坏状态通知（Explicit Bad State Notification，EBSN [BBKVP96]）

 

-          向接收方发出的显式丢包通知（Explicit Loss Notification to the Receiver ，ELNR）和显式延迟复制包激活通知（Explicit Delayed Dupack Activation Notification ，EDDAN），即移动接收端的通知[MV97]

 

-          显式拥塞通知（Explicit Congestion Notification，ECN）[ECN]

 

在上述建议中，显式拥塞通知（Explicit Congestion Notification ，ECN）看来与Internet上的配置最为接近，可为远程窄带网络中的TCP连接（或所有其它类型的TCP连接）提供一些好的特性。

 

       建议：目前尚无此建议。已经列出来的，作为未来研究有ELNR和EDDAN [MV97]，这两种通知方式都只需要修改中间介质结点及移动设备的系统。然而这种解决方式还有一些局限性，因为中间结点也必须解读TCP头，这意味着IP的有效负载部分不可以加密。

 

       ECN在IP头中使用TOS字节来装载拥塞信息（ECN支持和产生拥塞，ECN-capable and Congestion-encountered）。该字节没有用IPSEC方式加密，因而ECN可以用于使用IPSEC方式加密的TCP连接中。

 

       建议：实现ECN。否则，也要建立相应的显式错误通知及跟踪机制。

 

       注意：ECN提供的一些信息有助于避免境况进一步恶化，但是对于无线应用来说，还有一定的局限性。有ECN（ECN-capable）支持的TCP连接不应解释没有标记ECN的信息包，从而主动地为其提供中继，相反，在极端的网络拥塞期间，路由器可能会因其缓冲区耗尽而丢弃含有显式通知标记的信息包，准确地说，是在主机在错误的时刻开始主动性地中继（retransmitting aggressively）。

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 20]