[tcpm] Re: using SACK info for RTTM?

[Neal Cardwell <[e-mail]>]

IMHO by far the biggest benefit of TCP timestamps is not in RTT measurement
or PAWS, but in using them for "Eifel" undo (a la RFC 3522, RFC 4015):
quickly detecting spurious loss detection events due to reordering, and
quickly undoing the spurious congestion control slow-down response. This is
important since reordering is increasingly common due to many increasingly
common network mechanisms: link-layer retransmissions for wifi/cellular
links, traffic engineering, multipathing and ECMP/WCMP load-balancing,
protective load balancing (SIGCOMM 2022), protective reroute (SIGCOMM
2023), multi-queue NICs, etc. Those factors make the 12 bytes of TCP option
space overwhelmingly worth it.

best regards,
neal


On Wed, Jun 5, 2024 at 3:03 AM Yoshifumi Nishida <[e-mail]> wrote:

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