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

Bob Briscoe <> Sun, 14 March 2021 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 583E53A09E1 for <>; Sun, 14 Mar 2021 16:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4gOngeGR7u3U for <>; Sun, 14 Mar 2021 16:33:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 977F83A09BE for <>; Sun, 14 Mar 2021 16:33:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uxvYnRbAYJAS5GXiQX8g/zyD3fJbwNlhVk4qnhwBsB0=; b=GwUCSrnscPJw3/bKYeR/4TrTWq q0k2Qpol0vcpcX9GYU9WjSLwI1eeVIfl+cOoG86JxkMxIwC4SKa7czzlcIO5zmcN7WhYge/S5JzT5 YBfWRHO94Wqtd00QrE1Qi+yNZ0pF5wB31KfYl1D+Na72M2L4bJYZ4Auc6eIhigbdl8TCyElJwYvoJ Pl9GD6pH2OOZ0K7KXlzO4nJ798EnBJF1SUk9cNXhTdX8MJAw7a9L58K5U6BH4cNqwK3zRIZC4Bk1l Sg/ldlTbtOgsckmvA2qAFYsvifzW8Kit/I+RNDR4Ku2mrkOy8Kbclu+7JBkL+uGxbc0CWAp9aECA1 V6ENbtag==;
Received: from ([]:34302 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lLaEy-0005Qd-Je; Sun, 14 Mar 2021 23:33:44 +0000
From: Bob Briscoe <>
To: Carles Gomez Montenegro <>,
References: <> <>
Message-ID: <>
Date: Sun, 14 Mar 2021 23:33:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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: Sun, 14 Mar 2021 23:33:49 -0000


An alternative encoding idea would be a 2-bit field (unspecified where 
at the point, but 2 bits might be small enough to extend some other 
related option).

00 : hold
01: increase
10: set to 1
11: decrease

(If you want, you can think of this as a 2-bit signed integer in 2s 
complement arithmetic, with 10 as a special case ;)

The increase/decrease might either be defined as +/- 1 or 
multiply/divide by 2 (i.e. bit-shift +/- 1).

This would be rather delicate, being sensitive to loss and reordering. 
But it has the advantage of compactness.
It does not support the ignore reordering feature in recent drafts, but 
I'm not sure how necessary that is.


On 14/03/2021 23:20, Bob Briscoe wrote:
> 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...
> 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.
> 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.
> ==Capability negotiation==
> * The description of the handshake isn't complete. It only describes 
> the SYN, not the SYN-ACK.
> * 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.
> 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"? Also, does a retransmission have 
> to have the same TARR option on it as the original (I would say not)?
> 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.
> I don't think the units should be "per full-sized data segment". They 
> should just be "per data segment".
> 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. As well as IPsec, you 
> could mention the TCP Authentication Option. 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.
> 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.
> Bob
> On 26/02/2021 13:22, Carles Gomez Montenegro wrote:
>> Dear TCPM WG,
>> As it can be seen below, we recently updated the TCP ACK Rate Request
>> (TARR) option draft.
>> Main changes:
>> - There are now two formats: a shorter one to announce support of the 
>> option, and a larger one which conveys the value of R, among others.
>> The two formats can be distinguished by the "Length" field value (while
>> keeping the same "Kind" value).
>> - In the second format, the Ignore Order field is now reduced to just 1
>> bit, and "R" is reduced to 7 bits. Therefore, the total format size
>> decreases from 7 bytes to 6 bytes.
>> - We added content in the security considerations section.
>> Also, after submission of the draft, we contacted IANA to request
>> allocation of ExID 0x00AC (aiming to somehow allude to "ACK") for the
>> option, as it is an RFC 6994-style experimental TCP option. The ExID 
>> value
>> has already been allocated:
>> Comments are welcome!
>> Thanks,
>> Carles (on behalf of the authors)
>> ---------------------------- Original Message 
>> ----------------------------
>> Subject: New Version Notification for
>> draft-gomez-tcpm-ack-rate-request-02.txt
>> From:
>> Date:    Fri, February 19, 2021 3:30 pm
>> To:      "Carles Gomez" <>
>>           "Jon Crowcroft" <>
>> -------------------------------------------------------------------------- 
>> A new version of I-D, draft-gomez-tcpm-ack-rate-request-02.txt
>> has been successfully submitted by Carles Gomez and posted to the
>> IETF repository.
>> Name:        draft-gomez-tcpm-ack-rate-request
>> Revision:    02
>> Title:        TCP ACK Rate Request Option
>> Document date:    2021-02-19
>> Group:        Individual Submission
>> Pages:        8
>> URL:
>> Status:
>> Htmlized:
>> Htmlized:
>> Diff:
>> Abstract:
>>     TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism
>>     that allows reducing protocol overhead in many scenarios. However,
>>     Delayed ACKs may also contribute to suboptimal performance. When a
>>     relatively large congestion window (cwnd) can be used, less frequent
>>     ACKs may be desirable.  On the other hand, in relatively small cwnd
>>     scenarios, eliciting an immediate ACK may avoid unnecessary delays
>>     that may be incurred by the Delayed ACKs mechanism.  This document
>>     specifies the TCP ACK Rate Request (TARR) option.  This option 
>> allows
>>     a sender to indicate the ACK rate to be used by a receiver, and it
>>     also allows to request immediate ACKs from a receiver.
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
>> _______________________________________________
>> tcpm mailing list

Bob Briscoe