Re: [tcpm] TARR - the two options for R Wed, 06 July 2022 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6139AC157B5B for <>; Wed, 6 Jul 2022 10:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rVtlI-QGwshc for <>; Wed, 6 Jul 2022 10:56:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18C27C157B39 for <>; Wed, 6 Jul 2022 10:55:59 -0700 (PDT)
Received: from (unknown [IPv6:2a02:8109:1140:c3d:2537:a596:442:bed]) (Authenticated sender: macmic) by (Postfix) with ESMTPSA id 828F2759A03BF; Wed, 6 Jul 2022 19:55:56 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_35B1CF04-8A8A-4162-99D4-B4C06F7B5B0C"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
X-Priority: 3 (Normal)
In-Reply-To: <>
Date: Wed, 06 Jul 2022 19:55:54 +0200
Cc: tcpm IETF list <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Carles Gomez Montenegro <>
X-Mailer: Apple Mail (2.3696.100.31)
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: Wed, 06 Jul 2022 17:56:04 -0000

> On 6. Jul 2022, at 19:16, Carles Gomez Montenegro <> wrote:
> Hi Michael,
> Many thanks for your response!
> Please find below my inline comments:
> <snip>
>>> Are there other opinions?
>> Hi Carles,
>> I would like to give some feedback as an individual.
>> This feedback is based on using your draft in one of my courses
>> at university resulting in a prototype implementation for FreeBSD
>> and packetdrill.
> This is great news!
> Your implementation-based feedback is highly appreciated.
>> Here are some points:
>> 1. You might want to say which kind (253 or 254) is used on the
>>   sender side and on the receiver side. The prototype accepts
>>   both on the receiver side and uses only one on the sender side.
>>   Which one is used on the sender side is compiled into the code.
> Yes, there is a TBD currently in the draft (-04). For -05, our current
> proposal is to use 254.
Great, thanks for the information.
>> 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.
>> 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...
> 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.
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.
> 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?

Best regards
> Cheers,
> Carles
>> Best regards
>> Michael
> _______________________________________________
> tcpm mailing list