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

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

Hi Gorry, Bob, Jonathan, (and list,)

Apologies for such a late response.

As will be presented in few hours in TCPM, the main updates in the latest
version of the draft (-04) aim to provide [1]:
- A general statement (on what overrides TARR and what is overriden by
TARR).
- A survey of specifications that provide rules on generating ACKs in
special conditions (see Appendix B).
- Explicit additional text to the TARR receiver behavior (section 3.2) when
necessary.

Thanks for your feedback. I look forward to knowing your opinion regarding
the above updates (again, to be presented in few hours).

Cheers,

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm
-ack-rate-request-04



<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Libre
de virus.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 6 Nov 2023 at 18:10, Gorry Fairhurst <[e-mail]> wrote:

> On 06/11/2023 16:58, Bob Briscoe wrote:
> > Jonathan,
> >
> > On 06/11/2023 16:37, Jonathan Morton wrote:
> >>> On 6 Nov, 2023, at 6:05 pm, Bob Briscoe
> >>> <in=[e-mail]> wrote:
> >>>
> >>> 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.
> >> Or, it might be feasible to just specify that any special conditions
> >> imposed by other RFCs, that require an immediate acknowledgement,
> >> also apply under TARR.  It's not necessary to enumerate all other
> >> possible RFCs that might have such a condition, as such an
> >> enumeration will inevitably become outdated.
> >>
> >> The only thing that TARR really overrides is the normal-case criteria
> >> for "delayed acknowledgements", in addition to providing one
> >> additional "special condition" for immediate acknowledgement.
> >> Wording that makes that clear should be sufficient.
> >
> > [BB] I suggested to Carles (f2f after the mtg) that it would be useful
> > for the draft to give a general statement of what overrides what (e.g.
> > RFCs that recommend or mandate immediate acks to signal congestion
> > trump TARR) which could be used for the future and for RFCs we haven't
> > found.
> >
> > But unless we've done a little bit of digging into which RFCs mandate
> > triggering ACKs and why, we can't really be sure we have a good set of
> > general statements. And giving specific examples will help
> > implementers to understand what the general statements mean.
> >
> >
> > Bob
> >
> +1 to setting a default rule and saying the "TARR" count is reset each
> time that an ACK is sent for any reason, and to doing a survey to find
> examples of specs where this happens.
>
> Gorry
>
> >>   - Jonathan Morton
> >> _______________________________________________
> >> tcpm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>