Monitoring QUIC/HTTP3 read and written bytes

[ladeak]

Background and motivation

I am looking for a reasonable way to monitor traffic (number of bytes received) on HTTP requests including HTTP/3.

I found a previous issue #41949 that allows to use a custom stream implementation for H2

However, I don't see that being viable for QuicConnetions and H3.

What I would prefer is something similar as described in #31003 by @karelz using monitoring.

However, the ReadAsync only seems to monitor the size of the buffer where the data is read into, but not the actual size of the received data:

if (NetEventSource.Log.IsEnabled())
{
    NetEventSource.Info(this, $"{this} Stream reading into memory of '{buffer.Length}' bytes.");
}

Is there an alternative approach to access this data?

API Proposal

I would be happy to use EventListener to collect the described data.

Ideally the event payload could store the size of the data without formatting it to string message.

API Usage

No new public API would be required.

Alternative Designs

No response

Risks

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I am looking for a reasonable way to monitor traffic (number of bytes received) on HTTP requests including HTTP/3.

I found a previous issue #41949 that allows to use a custom stream implementation for H2

However, I don't see that being viable for QuicConnetions and H3.

What I would prefer is something similar as described in #31003 by @karelz using monitoring.

However, the ReadAsync only seems to monitor the size of the buffer where the data is read into, but not the actual size of the received data.

Is there an alternative approach to access this data?

API Proposal

I would be happy to use EventListener to collect the described data.

Ideally the event payload could store the size of the data without formatting it to string message.

API Usage

No new public API would be required.

Alternative Designs

No response

Risks

No response

Author:	ladeak
Assignees:	-
Labels:	api-suggestion, area-System.Net.Http
Milestone:	-

[ManickaP]

Are you interested in HTTP payload size or bytes received on QUIC level? HTTP/3 has its own framing, which would count as part of QUIC bytes, but wouldn't count into actual HTTP payload bytes.

[ladeak]

I would be interested in the Quic bytes which includes the H3 frames.

[ladeak]

@ManickaP or @karelz do you have any suggestions?

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I am looking for a reasonable way to monitor traffic (number of bytes received) on HTTP requests including HTTP/3.

I found a previous issue #41949 that allows to use a custom stream implementation for H2

However, I don't see that being viable for QuicConnetions and H3.

What I would prefer is something similar as described in #31003 by @karelz using monitoring.

However, the ReadAsync only seems to monitor the size of the buffer where the data is read into, but not the actual size of the received data:

if (NetEventSource.Log.IsEnabled())
{
    NetEventSource.Info(this, $"{this} Stream reading into memory of '{buffer.Length}' bytes.");
}

Is there an alternative approach to access this data?

API Proposal

I would be happy to use EventListener to collect the described data.

Ideally the event payload could store the size of the data without formatting it to string message.

API Usage

No new public API would be required.

Alternative Designs

No response

Risks

No response

Author:	ladeak
Assignees:	-
Labels:	api-suggestion, untriaged, area-System.Net.Quic
Milestone:	-

[ManickaP]

At the moment, no suggestions. This will need change in production code. If you were the one calling Quic, you'd now the amount of bytes. If you were interested in H/3 bytes, then this would be nice suggestion for HTTP telemetry. But this is neither, so I'm inclined to push this to future.

If you really need this, we would take a contribution for 8.0. And if you'd be willing to do this, please let us know and talk about potential solutions before diving into implementation.

[ladeak]

I am busy in the coming weeks, but I can return here in the summer and discuss potential solutions before contributing.

[ManickaP]

Awesome, thanks!
Just FYI, we have a feature freeze in the first half of July, so your potential change might end up in .NET 9.0 instead of 8.0.