Re: [Editorial Errata Reported] RFC9114 (7702)

2023-11-14 Thread Rebecca VanRheenen
Hi Zahed, We are unable to verify this erratum that the submitter marked as editorial. Please note that we have changed the “Type” of the following errata report to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at

[Editorial Errata Reported] RFC9114 (7702)

2023-11-14 Thread RFC Errata System
The following errata report has been submitted for RFC9114, "HTTP/3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7702 -- Type: Editorial Reported by: Lucas Pardue Section: 10.7

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Lucas Pardue
On Tue, 14 Nov 2023, 20:19 Damien Neil, wrote: > On Tue, Nov 14, 2023 at 12:01 PM Lucas Pardue > wrote: > >> Why not? >> > > I think what I wanted to say is that you don't want to require every qlog > consumer to have both a QUIC wire protocol frame parser and a qlog event > Frame parser.

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Marten Seemann
As I see it, the problem we're discussing here is *not* a qlog problem. It's a general problem with the ACK delay on ACKs received in Initial and Handshake packets, both of which might be received before processing the transport parameters. We discussed this in

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Damien Neil
On Tue, Nov 14, 2023 at 12:01 PM Lucas Pardue wrote: > Why not? > I think what I wanted to say is that you don't want to require every qlog consumer to have both a QUIC wire protocol frame parser and a qlog event Frame parser. Frames in qlog should be either structured objects (in practice,

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Lucas Pardue
On Tue, 14 Nov 2023, 16:25 Damien Neil, wrote: > I agree with Marten that logging the raw frame isn't a great option. You > don't want to have to stick a frame parser in every qlog consumer. > Why not? Applications that use QUIC increasingly make use of QUIC's variable length encoding. For

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Damien Neil
I agree with Marten that logging the raw frame isn't a great option. You don't want to have to stick a frame parser in every qlog consumer. I'd still like to know how a producer is supposed to log ack_delay prior to knowing the peer's max_ack_delay parameter. Are producers just expected to not

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Marten Seemann
I had always assumed that RawInfo only applied to the payload of the STREAM and DATAGRAM frame. Looking at the definition of RawInfo, it looks like my assumption was likely wrong :) While I can see potential value in logging the data sent in STREAM / DATAGRAM frames, I don't think there's

Re: qlog, AckFrame, and ack_delay

2023-11-14 Thread Robin Marx
Hello all, Sorry for the late reply from my end; I had some troubles posting to the list and my original reply got lost in moderation. I can appreciate both sides of the argument here. Originally I tended more towards Damien's suggestion and opened a PR for it at