[tcpm] Re: using SACK info for RTTM?

[Yuchung Cheng <[e-mail]>]

hi Yoshifumi,

Linux only uses TS-opts if needed to disambiguate on RTT samples covering
sequences that have been retransmitted. This applies to SACK or non-SACK.
In order words, if an S/ACK covers a sequence range that has never been
retransmitted, Linux does not use timestamp options.

On Mon, Jun 3, 2024 at 1:29 PM Yoshifumi Nishida <[e-mail]> wrote:

> 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]
>>>
>> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>