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

From: Martin Duke via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 11:55:02 -0800

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"?

---

From: Carsten Rossenhoevel <[email-masked]>
Date: Wed, 2 Feb 2022 08:06:27 +0100

Dear Martin,

Thank you very much for your review.

Re 4.3.1.3: The reference is a mistake indeed.  Amazing that nobody 
spotted it before :-(  We will fix it to be RFC 7540.

Re 4.3.3.1: TCP persistence allows to send multiple HTTP requests using 
a single TCP connection.  We got used to this term during the drafting 
sessions; but I think a more precise and more frequently used term in 
the industry is "HTTP persistence".  Does it improve the text from your 
point of view if we rename "TCP persistence stack" to "HTTP persistent 
connections"? (https://en.wikipedia.org/wiki/HTTP_persistent_connection)

Re 4.3.1.1, 4.3.2.1: Your question regarding delayed ack requires more 
analysis with contributors.  Please bear with us.  I hope to have a 
coordinated response for you later today.

Best regards, Carsten

-- 
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 +49.177.2505721
[email-masked], 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

---

From: Martin Duke <[email-masked]>
Date: Wed, 2 Feb 2022 07:23:00 -0800

> spotted it before :-(  We will fix it to be RFC 7540.

I would recommend draft-ietf-httpbis-http2bis-07
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/>, but sure.

> connections"? (https://en.wikipedia.org/wiki/HTTP_persistent_connection)

Yes, that's fine. Or just define the term.

> coordinated response for you later today.

Sure thing.

> > Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/

---

From: Carsten Rossenhoevel <[email-masked]>
Date: Thu, 3 Feb 2022 02:03:48 +0100

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

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 10:36:40 -0500

Martian,

Do you have any suggestions in response to Carsten's questions to you?

Brian

-----Original Message-----
From: Carsten Rossenhoevel <[email-masked]> 
Sent: Wednesday, February 2, 2022 8:04 PM
To: Martin Duke <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Al Morton <[email-masked]>
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:
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> (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
> 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].
>
--
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 +49.177.2505721 [email-masked], 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

---

From: Martin Duke <[email-masked]>
Date: Tue, 15 Feb 2022 09:53:58 -0800

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 <[email-masked]> wrote:

> Cc: [email-masked]; [email-masked];
> [email-masked]; Al Morton <[email-masked]>
> 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.
> Salzufer 14, 10587 Berlin, Germany office +49.30.3180595-21, fax
> +49.30.3180595-10, mobile +49.177.2505721 [email-masked],
> https://www.eantc.de
>
> Chairman/Vorsitzender des Aufsichtsrats: Herbert Almus Managing
> Directors/Vorstand: Carsten Rossenhövel, Gabriele Schrenk