[tcpm] ack-rate-request-03: which other RFCs take precedence?

[Bob Briscoe <[e-mail]>]

Carles,

For the list, I'll repeat what I just said at the mic:
There are certain TCP RFCs that identify specific circumstances where 
the receiver ought to emit an ACK.

Clearly ack-rate-request overrides those that define the regular delayed 
ACK mechanism.
But others talk about triggering an immediate ACK when there's a 
possible loss, or an ECN-,CE indicating congestion.

We're going to need to specify carefully which RFCs are overridden by 
ack-rate-request, and which are not.

Here's the start a list:

  * Host requirements [RFC1122]
  * SACK [RFC2018]
  * DSACK [RFC2883]
  * Reno [RFC5681]
  * AccECN [draft-ietf-tcpm-accurate-ecn]

I found one that doesn't seem to discuss triggering any ACK (when I 
thought it might:

  * RFC3168


Also, here's the issue that Marten Seemann raised, which prompted me to 
think of this:
https://github.com/quicwg/ack-frequency/issues/244


Bob

On 06/10/2023 18:13, Carles Gomez Montenegro wrote:
> Dear TCPM WG,
>
> Please find below the pointers to our last revision of the TCP ACK 
> Rate Request (TARR) option draft.
>
> The updates are intended to address the comments received in IETF 117:
>
> - Section 3.2: clarifications regarding the autonomous decision of a 
> receiver to send an ACK regardless of the ACK Rate requested, when 
> losses or reordering occur.
>
> - Section 5.3: wordsmithing the text on triggering a sufficient number 
> of ACKs per round trip in the presence of stretch ACKs (thanks to Ian 
> Swett!).
>
> - Further minor clarifications throughout the document.
>
> Comments are welcome and appreciated!
>
> Cheers,
>
> The authors
>
>
>
> On Fri, 6 Oct 2023 at 19:04, <[e-mail]> wrote:
>
>     Internet-Draft draft-ietf-tcpm-ack-rate-request-03.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-03.txt
>        Pages:   14
>        Dates:   2023-10-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-03
>
>     A diff from the previous version is available at:
>     https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-ack-rate-request-03
>
>     Internet-Drafts are also available by rsync at:
>     rsync.ietf.org::internet-drafts
>
>
>     _______________________________________________
>     tcpm mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/