Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-rate-request-02.txt]

Carles Gomez Montenegro <> Mon, 21 March 2022 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C15B03A1AB0 for <>; Mon, 21 Mar 2022 11:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 fyZvskYtJy4L for <>; Mon, 21 Mar 2022 11:35:41 -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 D0C7F3A1AAD for <>; Mon, 21 Mar 2022 11:35:31 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 22LIYj6X056543; Mon, 21 Mar 2022 19:34:45 +0100
Received: from ( []) by (Postfix) with ESMTP id 8CB971D53C1; Mon, 21 Mar 2022 19:34:44 +0100 (CET)
Received: from by with HTTP; Mon, 21 Mar 2022 19:36:14 +0100
Message-ID: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 21 Mar 2022 19:36:14 +0100
From: Carles Gomez Montenegro <>
To: Bob Briscoe <>
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.5 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 00:22:03 by milter-greylist-4.3.9 ( []); Mon, 21 Mar 2022 19:34:45 +0100 (CET)
Archived-At: <>
Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-rate-request-02.txt]
X-Mailman-Version: 2.1.29
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: Mon, 21 Mar 2022 18:35:44 -0000

Hi again, Bob,

Thanks as well for this third message of yours.

Please find below my inline responses:

> Carles,
> I've written a few of my review comments about
> draft-gomez-tcpm-ack-rate-request-02 in the two recent threads about
> this draft. Here are the remainder...

Thank you very much for your comprehensive feedback!

> I think it would be useful at this stage to describe the pros and cons
> of one or two alternative encoding schemes, rather than just assert one
> scheme.

In -03 they are briefly described (as "OPTION 1" and "OPTION 2").

The first encoding is simple, but it is limited to a maximum value of 63.

The second encoding is more complex, but it covers a greater range of
values, with a maximum value of 1024 and lower granularity for high

> I don't believe the message can have the meaning "The receiver MUST
> modify its ACK rate to..." A TARR message can only be advisory (a
> request not an order), because the receiver might not have the resources
> to send ACKs as often as requested. Also, it would be an obvious attack
> (e.g. everyone gangs up on a server by disabling delayed ACKs and
> uploading loads of data). If the receiver does not comply it doesn't
> need to explicitly refuse the request, it just sends as frequently as it
> can in response.

Agreed. In -03, this was modified to a SHOULD. We also added reasons why
it is not a MUST, as per your comment above.

> ==Capability negotiation==
> * The description of the handshake isn't complete. It only describes the
> SYN, not the SYN-ACK.

Agreed. We have described the SYN-ACK now.

> * It occurs to me that initiating on the SYN isn't really necessary,
> because DelACKs do not start until after the SYN-ACK. Given lack of
> space on the SYN, how about saying the TARR option MUST NOT be on a SYN.
> If the server supports TARR, it includes the TARR option on the SYN-ACK,
> and it doesn't send any further TARR until it has seen a TARR option
> from the client.
> if the client supports TARR, it SHOULD respond with the TARR option on
> the first ACK and the first data packet (if there is one).
> If you don't like this, second-best would certainly be to aggregate with
> other options on the SYN (as in Yoshi's presentation), given option
> space on the SYN is so scarce.

Thanks for the proposal. It makes sense. Perhaps it would be good to know
what others may think about it, and we plan to ask in the tcpm meeting
about it.

> The scheme should define the semantics of a TARR message from sender to
> receiver. Does it mean "for this packet only" or "from this packet
> onwards until another TARR packet"?

It means the latter. We have clarified it in section 3.

> Also, does a retransmission have to
> have the same TARR option on it as the original (I would say not)?

Agreed, our answer is "no". Added in section 3.

> I notice you've stipulated that the TARR option is in the TCP header of
> a data packet. Is there any reason to preclude one on a pure ACK?
> Admttedly TARR on an ACK doesn't seem so useful, but if you do preclude
> it, code has to exist to specifically ignore TARR on a pure ACK, which
> seems to add unnecessary complexity.

Agreed. We removed the specific mention of "data" in "data packet".

> I don't think the units should be "per full-sized data segment". They
> should just be "per data segment".

We applied this update.

> Security Considerations:
> I'm not sure there's much point strongly recommending TLS in this doc,
> then saying it doesn't protect the TCP headers.

Actually, we aimed to provide a general picture for a reader, and
precisely then explain that TLS won't help protect the TCP headers.

> As well as IPsec, you
> could mention the TCP Authentication Option.

Agreed. Added in -03.

> I think you are entitled to
> say that it is still relatively hard for an off-path attacker to hijack
> an unprotected TCP session. It would be worth recommending that RFC5961
> is used to check packet validity. And say that TARR option MUST be
> ignored on a packet that is deemed invalid.

Agreed. Added in -03 as well.

> I've briefly collected together points I've made in other threads here:
> * N is redundant. There's no need to request immediate ACKs for N
> packets, when the sender can send an updated TARR request after N packets.
> * Rather than make R=0 have the special meaning of ACK every packet,
> ack-ratio = 1 already means that. So just define ack-ratio = R+1
> * Lower precision would be sufficient for higher ack ratios.
> * With a 6-bit field, could encode R as 4-bit mantissa plus 2-bit
> exponent, in base 4 or base 16.
>    o Then you'd have 2 bits spare, perhaps one for the "ignore
> reordering" flag (I) and one reserved for future use (always nice).
> * With the "ignore reordering" flag (I), I think the semantics of loss
> detection would need to be redefined.

I believe all the points above have been covered, pending the Ignore Order
discussion mentioned.


It does!!

Once again, many thanks,


> Bob