Thanks, Alexey.

quoted

    2. When a packet was SACKed but not retransmitted, the linux also
calculate the seq_rtt from it when there is no unSACKed packet in the

queue.

It is not used. When a segment fills a hole, tcp uses skb->when of the

segment

which _filled_ the hole. See?

Yes, this is exactly my question: When this segment fills a hole, it may be
SACKed before.
If it's SACKed before, that means its "round trip" had already finished
before this ACK came-- Now it's filling the hole just because some strange
things (such as ack loss) happened. So, I don't think we should use its
skb->when to estimate RTT. But in Linux, such a packet (SACKed) may still
provide RTT estimation.

What's about using SACKs to give additional feed to rtt estimator,
even when ACK is duplicate, it is intersting idea, I even read about
this somewhere. But we do not use this.

Actually, I am going to do that: Can I get a safe RTT estimation from SACK,
when the SACKed packet (in rtx queue) is never SACKed or Retransmitted?

-David