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

原创 2001年05月08日 13:03:00

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

 

 

       应答间隔要求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-impltcp-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。注意,这暗示了支持PAWSProtection Against Wrapped Sequence space)和RTTMRound 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 NotificationEBSN [BBKVP96]

 

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

 

-          显式拥塞通知(Explicit Congestion NotificationECN[ECN]

 

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

 

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

 

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

 

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

 

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

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 20]

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

         -  ESRO [RFC2188]       -  RDP [RFC908, RFC1151]       -  VMTP [VMTP] 3 TCP协议的状况(The Case f...
  • chifire
  • chifire
  • 2001年05月08日 13:03
  • 578

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

   -          允许延迟敏感的低速通信使用小包。 -          降低头的负载(通常的TCP段尺寸是512)。移动IP通道中IPv4/TCP的头负载可以从11.7%降到不足1%。 -...
  • chifire
  • chifire
  • 2001年05月08日 13:49
  • 775

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

    4.8 活动队列管理(Active Queue Management)              前面已经提过,TCP回应拥塞的方式是关闭窗口并调用慢启动。延迟时间长的网络在从此状况中恢复也需...
  • chifire
  • chifire
  • 2001年05月08日 13:45
  • 681

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

         相应地,移动装置在办公室的有线局域网和无线广域网间自由切换,而在此过程中,已建立的连接仍将继续而不发生中断,当然,这种类型的机动性需要有移动IP地址(Mobile IP [RFC20...
  • chifire
  • chifire
  • 2001年05月08日 13:02
  • 688

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

     -  共享网络性能信息(TCP控制块和拥塞管理模块)      有些信息不应当被共享。例如,TCP顺序号用来防止伪装攻击(spoofing attacks),甚至有关性能参数的共享都会给拒绝...
  • chifire
  • chifire
  • 2001年05月09日 12:16
  • 705

RFC2757-Long Thin Networks-chifire自译本(9)完

  [KRLKA97]      Kojo, M., Raatikainen, K., Liljeberg,  M., Kiiskinen,                  J., Alanko, ...
  • chifire
  • chifire
  • 2001年05月09日 12:18
  • 692

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

   -          分割TCP建议并不适合含有不对称路由的网络。要应用分割TCP方案,需要保证移动设备在中间介质节点间来去路由的畅通,而对一些网络来说,这要么是无法完成的,要么需要中间介质节点...
  • chifire
  • chifire
  • 2001年05月08日 13:47
  • 587

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

  Network Working Group                                      G. MontenegroRequest for Comments: 2757...
  • chifire
  • chifire
  • 2001年05月08日 12:59
  • 738

rfc1945-http1.0自译本-(4)

 3.2  统一资源标识(Uniform Resource Identifiers)        URI有许多名字,如WWW地址、通用文件标识(Universal Document Identifi...
  • chifire
  • chifire
  • 2001年02月16日 11:35
  • 628

RFC2617- HTTP Authentication自译本-(4)

        但它还是比在LDAP[10]、POP及IMAP(见RFC2195[9])上用的CRAM-MD5要强许多。它将被用来替代薄弱的危机四伏的基本机制。              分类鉴别只提...
  • chifire
  • chifire
  • 2001年02月16日 12:12
  • 1735
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:RFC2757-Long Thin Networks-chifire自译本(4)
举报原因:
原因补充:

(最多只允许输入30个字)