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

[Martin Duke <[e-mail]>]

On Tue, Feb 1, 2022 at 11:06 PM Carsten Rossenhoevel <[e-mail]> wrote:

> 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.
>

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


>
> 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)
>

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


>
> 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.
>

Sure thing.


>
> Best regards, 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 [phone], 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
>
>