[tcpm] Re: using SACK info for RTTM?

[Neal Cardwell <[e-mail]>]

On Mon, Jun 3, 2024 at 11:02 AM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi folks,
>
> While I was checking RFC7323, I found the following sentence.
>
> RTTM update processing explicitly excludes segments not updating
> SND.UNA.  The original text could be interpreted to allow taking
> RTT samples when SACK acknowledges some new, non-continuous
> data.
>
> I am a bit curious about the rationale of this sentence.
> It seems to me that we cannot measure RTT when we have a gap in packet sequence with this rule.
>
>
Yes, that rule forbids using RFC7323 timestamps for calculating RTT samples
for SACKed sequence ranges.

The rationale: AFAIK this rule is a necessary consequence of the conditions
under which TS.Recent is updated.

The rules for updating TS.Recent are in sec 4.3, "Which Timestamp to Echo":
  https://datatracker.ietf.org/doc/html/rfc7323#section-4.3
Rule (2) in sec 4.3 says:
  If:
    SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent
  then SEG.TSval is copied to TS.Recent; otherwise, it is ignored.

Since out-of-order sequence ranges that are SACKed will fail the SEG.SEQ <=
Last.ACK.sent check, SACKed sequence ranges will not update TS.Recent. So
using TS.Recent to calculate an RTT sample for a SACKed sequence range
could, in general, give a vastly overestimated RTT sample. So that's why
it's forbidden by the RFC.

However, in practice usually this does not need to be a big deal. For
example, Linux TCP still obtains an RTT sample for every non-retransmitted
SACKed sequence range, by:

(a) recording the transmit time of every sequence range
(b) recording whether that sequence range was retransmitted, and then
(c) using those two pieces of information when that sequence range is
cumulatively or selectively ACKed, to calculate an RTT sample (rtt_sample =
now - transmit_timestamp) if the sequence range was never retransmitted.

So, in Linux TCP, SACKed sequence ranges fail to generate an RTT sample
only when they were previously retransmitted.

best regards,
neal


> Thanks,
> --
> Yoshi
>
> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>