[tcpm] Fwd: I-D Action: draft-ietf-tcpm-ack-rate-request-08.txt

[Carles Gomez Montenegro <[e-mail]>]

Dear TCPM WG,

Please find at the end of this message the main pointers to an updated
version of the TCP ACK Rate Request (TARR) option draft.

Regarding the comments received in Bangkok [1]:

- @Michael: it turns out that your suggestion had already been included in
the document (long time ago!):

    In some cases (e.g. when SYN cookies are used [RFC4987]), the client
    MAY announce that it supports the TARR option in packets subsequent
    to the SYN packet.

- @Yoshi: aiming to address your comment, and perhaps as a starting point,
in -08 we reduced the requirement level of MUST to SHOULD (regarding
inclusion of a TARR option with an R value in the special case discussed),
and added a note on when/why it could be appropriate not to follow the
required (SHOULD-level) behavior:

   When a retransmission is triggered by retransmission timer
   expiration, if the sender knows that the TCP receiver is TARR-
   capable, and the last R value requested by the sender different from
   zero is greater than 2, the segment carrying retransmitted data
   SHOULD carry a TARR option with R set to 1.  (Note: In any other
   circumstances, a TCP segment carrying retransmitted data is not
   required to include a TARR option.)  Once the sender determines that
   all retransmitted data has been acknowledged, the first segment
   carrying only new data SHOULD carry a TARR option with R set to 2.
   When a TARR option with R=2 is sent, the receiver is requested to
   revert to default Delayed ACKs operation [RFC 1122].

   Note that, even if TARR has been successfully used in an on-going TCP
   connection, the path from source to destination may change to a new
   one where packets carrying the TARR option might not be supported
   (e.g., due to a TARR-unfriendly middlebox).  Not including the TARR
   option in a retransmitted packet, or in the first packet carrying
   only new data, is a conservative approach that may prevent such
   packets from being discarded in a possible such new path.


Also, as discussed in Bangkok, it would be great if we could get reviews,
not only of the items above, but of the whole document in its current
version.

Many thanks!

Cheers,

Carles and Jon






[1]
https://datatracker.ietf.org/meeting/122/materials/minutes-122-tcpm-202503210600-00

---------- Forwarded message ---------
From: <[e-mail]>
Date: Tue, 6 May 2025 at 16:21
Subject: [tcpm] I-D Action: draft-ietf-tcpm-ack-rate-request-08.txt
To: <[e-mail]>
Cc: <[e-mail]>


Internet-Draft draft-ietf-tcpm-ack-rate-request-08.txt is now available. It
is
a work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the
IETF.

   Title:   TCP ACK Rate Request Option
   Authors: Carles Gomez
            Jon Crowcroft
   Name:    draft-ietf-tcpm-ack-rate-request-08.txt
   Pages:   19
   Dates:   2025-05-06

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 request the ACK rate to be used by a receiver, and it
   also allows to request immediate ACKs from a receiver.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-ack-rate-request/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ack-rate-request-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-ack-rate-request-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
tcpm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]