Chinaunix

标题: TCP FACK的一个问题 [打印本页]

作者: goingstudy 时间: 2017-04-28 22:03
标题: TCP FACK的一个问题
在TCP的FACK中有这么一个条件：

if the sender receives an ACK which advances snd.fack beyond the value of snd.nxt at the time a segment was retransmitted (and that retransmitted segment is otherwise unaccounted for), the sender knows that segment which was retransmitted has been lost.

这是FACK的论文里的，意思就是如果发送端收到了一个ACK，而且这个ACK使snd.fack 大于了这个段重传时的snd.nxt,那么可以断定这个重传的段丢失了（不知道翻译的正确不）

FACK 链接

谁能解释一下为什么能断定丢失了？

作者: jerryhua_cu 时间: 2017-05-03 11:31
我觉得作者的本意是，算法优先发送重传的数据包，一个ack可以减少retran_data或者增加snd.fack，在有重传的情况下，如果收到的ack直接推进了snd.fack而不是减少retran_data，那么就是收到了后面的数据，而优先发送的重传包反而丢失了。

作者: goingstudy 时间: 2017-05-04 20:53
回复 2# jerryhua_cu

那又可能是重传的数据在网络中被delay了吗？这种可能性是怎么排除的？

作者: jerryhua_cu 时间: 2017-05-09 18:32
有可能乱序，作者也许是认为这种可能性极低所以统一当做丢包处理。就和FS一样，收到3个dupACK就开启重传，是否有可能3个dupACK以后又收到能让窗口右移的ack呢？实际上也是有可能的，只不过这种可能性比较低。

作者: goingstudy 时间: 2017-05-10 12:23
回复 4# jerryhua_cu
好吧，感觉像是根据经验得出来的

作者: goingstudy 时间: 2017-07-27 11:31
回复 4# jerryhua_cu

对，确实是那样，在96年，乱序几乎没有（ecmp route 不多）。但是我还有个问题，fack是sack block 最大序号加1，那么fack是不是就是最大的那个sack block 的右边界的序号加1？这样才有可能大于snd.nxt吧？

作者: goingstudy 时间: 2018-05-11 19:28
回复 6# goingstudy

是这样的，在linux 里与这个对应的是tp->highest_sack /* skb just after the highest skb with SACKed bit set */

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)