[tcpm] Re: using SACK info for RTTM?

[Yoshifumi Nishida <[e-mail]>]

Hi Yuchung,

Thanks for the explanation.
I thought a bit about the trade-off between using 12 bytes options space
and giving up measuring RTTs for retransmitted packets.
But, I am included to prefer measuring RTTs for now.

--
Yoshi

On Mon, Jun 3, 2024 at 1:57 PM Yuchung Cheng <[e-mail]> wrote:

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