Re: [bmwg] Martin Duke's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)

[Martin Duke <[e-mail]>]

How about:

"Clients SHOULD NOT delay ACKs for more than 200ms past the receipt of the
first packet. Also, clients SHOULD NOT send an ack less frequently than for
every 10 received segments."

On Wed, Feb 9, 2022 at 7:37 AM <[e-mail]> wrote:

> Martian,
>
> Do you have any suggestions in response to Carsten's questions to you?
>
> Brian
>
> -----Original Message-----
> From: Carsten Rossenhoevel <[e-mail]>
> Sent: Wednesday, February 2, 2022 8:04 PM
> To: Martin Duke <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; Al Morton <[e-mail]>
> Subject: Re: Martin Duke's No Objection on
> draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)
>
> Martin,
>
> Here is a response to your second comment.  The authors have discussed the
> Delayed ACK statement once more.  In general, it would be possible to
> specify the limit in time in addition.  A typical value would be 200 ms
> (Windows OS default).  However, it is unclear to us if such a limit would
> cover any corner cases and whether it would generally reduce confusion
> instead of increasing it (problems with inclusive vs.
> exclusive "or" in normative statements).
>
> If you would still like us to add a delayed ack limit in time, could you
> please suggest specific text that - given your experience with IETF
> documents - would be consistent and represent the normative statements
> correctly?
>
> Apologies, it is not my plan to delegate our work to you :), but we are
> really unsure how to formulate this precisely.
>
> Thank you, Carsten
>
>
> Am 2/1/2022 um 8:55 PM schrieb Martin Duke via Datatracker:
> > Martin Duke has entered the following ballot position for
> > draft-ietf-bmwg-ngfw-performance-13: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (4.3.1.3) RFC8446 is not the reference for HTTP/2.
> >
> > (4.3.1.1), (4.3.2.1) Is there a reason that delayed ack limits are
> > defined only in terms of number of bytes, instead of time? What if an
> > HTTP request (for
> > example) ends, and the delayed ack is very long? Note also that the
> > specification for delayed acks limits it to every two packets,
> > although in the real world many endpoints use much higher thresholds.
> > [It's OK to keep it at 10*MSS if you prefer].
> >
> > (4.3.3.1) What is a "TCP persistence stack"?
> >
> >
> >
> --
> Carsten Rossenhövel
> Managing Director, EANTC AG (European Advanced Networking Test Center)
> Salzufer 14, 10587 Berlin, Germany office +49.30.3180595-21, fax
> +49.30.3180595-10, mobile [phone] [e-mail],
> https://www.eantc.de
>
> Place of Business/Sitz der Gesellschaft: Berlin, Germany
> Chairman/Vorsitzender des Aufsichtsrats: Herbert Almus Managing
> Directors/Vorstand: Carsten Rossenhövel, Gabriele Schrenk
> Registered: HRB 73694, Amtsgericht Charlottenburg, Berlin, Germany EU VAT
> No: DE812824025
>
>
>