Re: [tcpm] TARR - the two options for R

Carles Gomez Montenegro <> Thu, 07 July 2022 06:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73446C157B41 for <>; Wed, 6 Jul 2022 23:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.928
X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ha-pAayUjIld for <>; Wed, 6 Jul 2022 23:40:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 545EBC157B35 for <>; Wed, 6 Jul 2022 23:40:16 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 2676e28i025902; Thu, 7 Jul 2022 08:40:04 +0200
Received: from ( []) by (Postfix) with ESMTP id 2B5F01D53C1; Thu, 7 Jul 2022 08:38:55 +0200 (CEST)
Received: from by with HTTP; Thu, 7 Jul 2022 08:40:14 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 07 Jul 2022 08:40:14 +0200
From: Carles Gomez Montenegro <>
Cc: tcpm IETF list <>,
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.103.6 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 13:23:34 by milter-greylist-4.3.9 ( []); Thu, 07 Jul 2022 08:40:04 +0200 (CEST)
Archived-At: <>
Subject: Re: [tcpm] TARR - the two options for R
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jul 2022 06:40:22 -0000

Hi Michael,

>>> 2. Regarding the encoding of R: I prefer option 1.
>>>   This allows to use the value of 0 to be used to signal that
>>>   an ACK for this segment should be sent immediately, but no
>>>   persistent change of the ACK ratio should be performed.
>> I see. In this case, R=0 would be a special case (i.e., an exception),
>> since by default the ACK rate would be the one requested with values of
>> R
>> different from zero.
> Yes, two semantics:
> If R=0, just send an ACK immediately, don't change the rate.
> If R>0, change the rate.
> For SCTP we have a feature to request an immediate ACK: RFC 7053,
> now incorporated into RFC 9260, which is the current specification of
> the base protocol.

Perfect, thanks!

>>> 3. If the range 1 - 127 is considered too small, one might consider
>>>   using two bytes for the option value. Currently, the length of
>>>   the option is odd, and therefore TCP implementations might add
>>>   some padding (NOP) anyway, since other options used after the
>>>   connection establishment like the timestamp or the sack option
>>>   have an even length.
>> If some padding would typically be added by implementations to produce
>> an
>> even option length, then we can use your suggestion and define a
>> two-byte
>> field for R (perhaps keeping some reserved bit(s)).
>> With this approach -let's call it OPTION 3-, we could use a simple
>> binary
>> encoding for R. Probably, one detail to figure out (and, probably,
>> discuss) then would be which would be the maximum value for R...
> Yepp.
>> Any further thoughts?
>>> 4. If SYN cookies are used and one is not willing to not spend another
>>>   bit for representing TARR support, you might want to specify that the
>>>   client sends the TARR option on the ACK of the three way handshake.
>>>   That way a server willing to support the TARR option can "learn"
>>>   from the client that it is OK to send the TARR option by observing
>>>   that the client sends it. It can also be learned later...
>> If I recall correctly, Bob suggested this same idea. In IETF 113, Martin
>> asked if sending the TARR option in this way (on the ACK), and thus not
>> reliably, could be a concern.
>> If there is lack of SYN space, perhaps one approach could be to learn it
>> later as you suggest, and/or to allow sending the TARR option on the ACK
>> but explaining the mentioned caveat...
> Clarification: This is not about the option space in the SYN segments.
> It is a about a server not allocating any state when receiving the initial
> SYN segment. The server puts all information it needs in the ISS.
> See
> how the encoding works. If you want to encode TARR supported/no supported
> you would need 1 more bit, which means using a 23 bit MAC.
> Assuming that the client is initially in slow start, you want a rate of
> one in slow start, the client might send a TARR option with R=1 with
> the ACK anyway. Just noting that a server might need to wait until
> it received a TARR option before sending one might be worth noting.

Thanks for the detailed explanation.

Sure, we will incorporate your comment in -05.

>> Once again, many thanks for your input and for the prototype
>> implementation work!
> Do you want to present the current state at the next meeting?


We plan to request a presentation slot, at least for the current version
of the draft (-04), but most likely for -05, which we plan to submit
before the cutoff date.



> Best regards
> Michael