[tcpm] Re: using SACK info for RTTM?

[Yoshifumi Nishida <[e-mail]>]

Hi Yuchung, Neal, thank you so much. It’s interesting.

So, it might be a good time to revive
https://datatracker.ietf.org/doc/draft-yang-tcpm-ets/ ?

OTOH, I’m thinking why DSACK is not sufficient here.

Thanks,
—
Yoshi

On Wed, Jun 5, 2024 at 10:06 AM Yuchung Cheng <[e-mail]> wrote:

> Also TCP timestamp needs to really move to usec level for today's
> data-center networks, which Eric Dumazet finally upstreamed that feature
> (to opt-in). anything beyond 10us can't be used in Eifel
>
> On Wed, Jun 5, 2024 at 6:41 AM Neal Cardwell <[e-mail]> wrote:
>
>> 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]
>>>>>
>>>>