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

[Yoshifumi Nishida <[e-mail]>]

Hi Carles,

Thank you so much for updating the draft! I think the proposed text
looks good and the doc is mostly ready.
As a few minor things remain, I am thinking it might be better to
clarify the following points.

1: I think the draft clarifies the case where the retransmission timer
expires. but, I'm thinking we might need to add something for other
cases.
   In my understanding, the current logic won't change R value in case
of duplicate ACKs as receivers send back ACKs immediately
   during the recovery period based on RFC5681.
   So, I think this is fine, however, one concern I have here is after
reducing cwnd, there is a possibility that reduced cwnd becomes
smaller than R.
   In this case, we might want to adjust R to avoid performance
degradations. Do you have any opinions on this?

2: Also, if we want to clarify the cases for receiving duplicate ACKs,
I am wondering if we want to clarify the cases where retransmissions
    are triggered by RACK/TLP as well.

Thanks,
--
Yoshi


On Wed, May 7, 2025 at 12:47 AM Carles Gomez Montenegro
<carles.gomez=[e-mail]> wrote:
>
> 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]
> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]