Hello! > Hmmm... I dont understand this....so if reording can be detected, (i.e > we use timestamps, DSACK), the dupthreshold is increased
Yes. > implementation that might lead to increase in the number of > retransmissions, but leads to improvment in download time Hmm... I thought and still do not know. > couldnt figure it out,....also is there anywhere where the reordering > response of tcp linux described? (it seem dupthreshold is dynamically > adjusted based on the reordering history... but I was not able to find > out how...)... That's comment from tcp_input: * Reordering detection. * -------------------- * Reordering metric is maximal distance, which a packet can be displaced * in packet stream. With SACKs we can estimate it: * * 1. SACK fills old hole and the corresponding segment was not * ever retransmitted -> reordering. Alas, we cannot use it * when segment was retransmitted. * 2. The last flaw is solved with D-SACK. D-SACK arrives * for retransmitted and already SACKed segment -> reordering.. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
