Re: Weird TCP SACK problem. in Linux...

[Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>]

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