关于Linux TCP中超时重传定时器的疑问【还有点小问题】

jiufei19

哦，感谢eexplorer的解释。

另外，假设一个TCP实例并不支持SACK选项，那么如果该TCP在一个窗口中连续发出了N个分段，并且第1个分段发生了超时，则是否就意味着所有这N个分段都需要全部重发一遍？

eexplorer

如果没有sack的话，sender没办法知道到底是哪些包丢了，所以一旦发生timeout, tcp就会重传第一个包。好像这时的cwnd会调小，只允许重传第一个包，然后等回应，在根据ack的sequence在决定重传下一个包，直到收到ack的sequence > tp->high_seq才会跳出lost state.

[ 本帖最后由 eexplorer 于 2009-9-29 15:45 编辑 ]

jiufei19

>> 直到收到ack的sequence > tp->high_seq才会跳出lost state.

这里就表示发送方在上一个窗口中发出的所有分段都已确认了吧？

eexplorer

原帖由 jiufei19 于 2009-9-29 15:58 发表
>> 直到收到ack的sequence > tp->high_seq才会跳出lost state.

这里就表示发送方在上一个窗口中发出的所有分段都已确认了吧？

是的。

jiufei19

非常感谢！继续研究TCP

jiufei19

我又仔细阅读了下关于快速重传/快速恢复的rfc2581和rfc2001两篇文档，其中有一段话明确说明如下：
---------------------------------------------------------------------------------------------------
Furthermore, upon a 【timeout】 cwnd MUST be set to no more than the loss
window, LW, which equals 1 full-sized segment (regardless of the
value of IW). Therefore, 【after】retransmitting the dropped segment
the TCP sender uses the 【slow start】algorithm to increase the window
from 1 full-sized segment to the new value of ssthresh, at which
point congestion avoidance again takes over.
------------------------------------------------------------
显然，上述原文明确说明了如果是因为超时重传事件发生，则拥塞窗口cwnd将被设置为不超过1个full-sized分段大小，然后立刻进行丢失分段的重发，接着通过慢启动来恢复拥塞窗口直至进入拥塞避免过程，于是是否可以这样理解，即重发是不受cwnd限制的，当重发完毕后，因为是慢启动，所以仍然可以再发送下一个新分段，于是在我这里提出的问题上下文中，就是先重发S1，然后再次重发S2（此时显示了没有sack时，tcp性能降低了，因为S2完全可能被正确收到过），此时发送方将停止发送，开始等待来自接收方的新的ACK的到来。

而eexplorer的原话是：
>> 如果没有sack的话，sender没办法知道到底是哪些包丢了，所以一旦发生timeout, tcp就会重传第一个包。好像这时的cwnd会调小，只允许重传第一个包，然后等回应

所以我想知道我的补充说明是否正确？ 即到底是否可以在重传S1后，再发送S2（此时因无sack，所以S2被作为新的数据分段对待），还是说只能重发S1后就等待？ 谢谢！

[ 本帖最后由 jiufei19 于 2009-9-30 16:19 编辑 ]

eexplorer

不好意思，我把recovery和loss有点搞混了，多谢指正。

重新看了一下alexey kuznetsov的那篇文档

一旦发生retrans timeout的话，tcp立即进入loss状态，所有从snd_una -> high_seq之间的包都会被认为是丢失了。然后tcp把cwnd设成1,使用slow start重发所有丢失的包。也就是说，假设S1 timeout了，TCP先发S1,收到ack后，cwnd加1，然后发送S2, S3。
lost和sack没什么关系。

sack的话，对于recovery是会有帮助的，因为有了sack的信息，sender可以知道那些包丢失了，可以有选择性的重发。

CUDev

超时重传，说明网络上有严重的拥塞，启用慢启动过程；收到三个相同的ACK报文，说明网络上有轻度的拥塞，启动快速重传和快速恢复过程。

jiufei19

感谢eexplorer的说明，其实我一直对tcp的拥塞控制原理缺乏真正清晰的认识，反复看了几遍和拥塞控制相关的rfc文档，我发觉自己还是糊涂，所以希望eexplorer能进一步帮我指正，下面我先描述下我的问题：（均以我在此帖中举出的S1,S2,S3分段丢失为例）

1、因重传超时定时器到时所引发的分段丢失事件，将怎样导致发送方进行重传和恢复？ 具体说就是重发丢失分段后能否继续发送新分段？
2、因连续收到3个重复ACKs所引发的分段丢失事件，将怎样导致发送方进行重传和恢复？ 具体说就是重发丢失分段后能否继续发送新分段？
3、为啥在无SACK支持下，存在如下一个由FF96文献所描述的固有性能低下问题，描述如下：
-----------------------------------------------------
[FF96]-- Simulation-based Comparisons of Tahoe, Reno, and SACK TCP
In the absence of SACK, both Reno and New-Reno senders can retransmit at most one dropped packet per round-trip time, even if senders recover from multiple drops in a window of data without waiting for a retransmit timeout.
>> 译文：在无SACK下，Reno和New-Reno发送方在每个RTT时间内，只能重发一个丢失的分段，即便发送方从一个窗口内有多个分段丢失情况下进行恢复时，不需要等待超时重发定时器到时。

上文说明了，如果一个窗口内有多个分段丢失，效率就很低下了，理想情况是能在一个RTT内尽量重发出多个丢失分段，而不是每次必须等待一个RTT才能重发一个丢失分段。 相反，若一个窗口内只有一个分段丢失，则反正只有一个丢失的，因此在一个RTT内重发一个就不会有性能问题了
-----------------------------------------------------

目前我参考了rfc2001， rfc2581， rfc2582，[FF96]中关于拥塞控制部分的描述，但是看完这些资料后，我自己忽然发觉更加昏了，落实到具体的慢启动，拥塞避免，快速重传/快速恢复算法描述中时（rfc2001， rfc2581，rfc2582），我始终无法完全确认如下两个问题：
a、重发丢失分段后（分两种情况，超时重发，3-dup ACKs），到底能否立刻发送下一新分段？
b、为啥在一个窗口中有多个分段丢失时，TCP存在性能问题，FF96中我不能理解体现上述缺陷的描述。

总之，我感觉我现在没有理解的根本原因就是，在收到连续3个重复ACKs，或者超时重发到时后，具体的处理细节到底怎样的，我始终没有真正掌握，希望大家能帮我解答，谢谢！

作为一个对照，请看eexplorer的解释（造成我发晕的一个原因）
>> 一旦发生retrans timeout的话，tcp立即进入loss状态，所有从snd_una -> high_seq之间的包都会被认为是丢失了。然后tcp把cwnd设成1,使用slow start重发所有>>丢失的包。也就是说，假设S1 timeout了，TCP先发S1,收到ack后，cwnd加1，然后发送S2, S3。

这里eexplorer说明了在重发S1后，需要等待该重发ack到来后，cwnd+1，然后才能发送S2, S3，但是在那几个rfc文档中我似乎没有看到需要等待重发分段到达后才能发新数据的描述，如下面文档的描述

另外，在“TCP and Successive Fast Retransmits”一文中（FF96的作者的另外一篇文章）有如下一段描述：
With Reno implementations, the source essentially assumes that only one packet has been dropped, retransmits that dropped packet, and instead of waiting for the ACK to be received, continues transmitted new packets.
显然此文表示了Reno算法在重发丢失分段后，并不是立刻停下来等待此丢失分段的ACK，而是可以继续发送新分段

还有在rfc2581中有如下描述：
----------------------------------------
1. When the third duplicate ACK is received, set 【ssthresh】 to no more
than the value given in equation 3.
>> 注意，此时没有发生重传超时事件，仅3个连续重复ACKs到来事件发生

2. 【Retransmit】 the lost segment and set 【cwnd】to ssthresh plus 3*SMSS.
This artificially "inflates" the congestion window by the number
of segments (three) that have left the network and which the
receiver has buffered.
>> 重发丢失分段，并且修改cwnd=ssthresh+3*SMSS（此时显然cwnd不为0，即允许发送端继续发送新数据，对比下面步骤4）

3. For each additional 【duplicate】 ACK received, 【increment】cwnd by
SMSS. This artificially inflates the congestion window in order
to reflect the additional segment that has 【left】the network.
>> 这些额外的仍然重复的ACK是因为在进入快速重发前发送方仍然在发送新的分段， 并且这些分段正确到达了接收方，此时可以增加cwnd

4. 【Transmit】a segment, if allowed by the new value of cwnd and the
receiver's advertised window.
>> 注意上述2，3，4步骤的顺序，即首先立刻重发，然后每收到一个重复ACK，就增加cwnd一个SMSS单位，此时可以发送新的分段（如果cwnd和rwnd允许的话）

显然步骤4中发送新分段并不需要等待重发分段的ACK的到来，并且步骤4和步骤3之间也无前后顺序关系

5. When the next ACK arrives that acknowledges 【new】 data, set cwnd to
ssthresh (the value set in step 1). This is termed "deflating"
the window.
>> 当上述第2步重发分段到达接收方后，接收方才能确认新的数据
-----------------------------------------------------------------

所以我现在很晕，望大家不吝赐教，待我彻底清楚后，写一个总结帖来回报大家的帮助，谢谢！


PS：
为了便于大家阅读，我上传了附件FF96

[ 本帖最后由 jiufei19 于 2009-10-2 17:06 编辑 ]

jiufei19

自己顶下，我又仔细阅读了下rfc2582，其中有如下说明，似乎部分说明了我之前说的FF96文献中那个缺陷，不知我的理解是否正确，请大家指正
---------------------------------------
In the case of 【multiple】packets dropped from a single window of data,
   the first 【new information】available to the sender comes when the
   sender receives an acknowledgement for the 【retransmitted】packet (that
   is the packet retransmitted when Fast Retransmit was 【first】entered).
   >> 因为一旦进入到快速重传过程，则发送方将立刻发送第1个导致dup-ACK的那个
   丢失的分段，只有当此重发分段被接收方正确收到，并作出确认后，发送方才能
   获知当前的最新状况，例如下面的示例：
   
            | *S1 | *S2  | S3  | S4  | *S5 |  S6  | S7  |   ...  |
      假定S1,S2,S5丢失，S3,S4,S6被正确收到，于是在S6被收到时进入了快速重传阶段，
   发送方开始重传S1，当重传的S1被接收方收到并确认后，发送方获得了所谓的new
   information（即发送方知道接收方现在开始期望接收S2了，而不再是S1这个old
   information），不过这里要注意，在S1被重传后，发送方并不是就一定必须等待
   接收方对此重发分段确认，而是可以继续发送新的数据分段，此时应该是S7（如果
   拥塞窗口允许的话），而不是S2，因为TCP只能进行累计确认，所以此时发送方只
   能知道S1丢失了。另外，因为S1进行重发，所以超时定时器被重新设置，假定此时
   重发的S1及时到达了接收方，并且接收方进行了ACK-2应答，于是发送方知道此时应该
   重发S2，假定此时再次进行重发S2，并且到达了接收方，于是接收方进行ACK-5应答，
   显然此时发送方将重发S5，依次类推，从这里可以看出每次重发如果到达接收方并
   返回了ACK的话，都是经过了一个RTT，所以，Reno是每个RTT内重发一个分段，效率
   比较低。
   
   If there had been a 【single】packet drop, then the acknowledgement for
  【this】 packet will acknowledge all of the packets transmitted before
   Fast Retransmit was entered (in the absence of reordering).  However,
   >> 显然这里的【this】是指重发的该分段，而重发那一时刻就是所谓的快速重发
   阶段的开始，很明显，此重发分段的确认必然会导致在此重发前所有已发出分段
   都被确认，并且如果在重发该分段后，cwnd允许继续发送新分段的话，那么再假设
   重发分段失序，在后续新分段到达后再到达，那么此时确认的分段将至少包括进入
   快速重传前所发出的所有分段，并加上部分后续分段；反之如果重发分段没有失序的话，
   那么重发分段到达后接收方确认的分段就将恰好是进入快速重传前所发出的所有分段

[ 本帖最后由 jiufei19 于 2009-10-2 19:19 编辑 ]