[tcpm] Re: using SACK info for RTTM?

[Yoshifumi Nishida <[e-mail]>]

Hi Neal, thank you so much for the comments.

The linux algorithm you've described makes sense to me and it seems the
scheme doesn't require timestamp options.
However, as far as I've read linux code, it seems that linux still uses
timestamp options for RTT measurement to some extent.
I'm curious why linux is mixing two schemes for RTTM.
--
Yoshi

On Mon, Jun 3, 2024 at 8:57 AM Neal Cardwell <[e-mail]> wrote:

>
>
> 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]
>>
>