[QUIC] Read can be highly inefficient

[wfurt]

I bump to this while looking at #56115

Consider the BigWrite_SmallRead_Success. We can receive 100b in single contiguous chunk and yet we would do 99 p/invokes to MsQuic and then receive 99 additional events via HandleEventRecv.

It feels like there is no point of informing MsQuic that we process something unless it is at least QuicBuffer.Length worth off data. There is no way IMHO it can return half of the buffer to the the OS.
Now, there is aspect that MsQuic can inform peer that some data were consumed but that only increases the inefficiency by sending extra data.

This probably needs deeper look.

[ghost]

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

Issue Details

---

I bump to this while looking at #56115

Consider the BigWrite_SmallRead_Success. We can receive 100b in single contiguous chunk and yet we would do 99 p/invokes to MsQuic and then receive 99 additional events via HandleEventRecv.

It feels like there is no point of informing MsQuic that we process something unless it is at least QuicBuffer.Length worth off data. There is no way IMHO it can return half of the buffer to the the OS.
Now, there is aspect that MsQuic can inform peer that some data were consumed but that only increases the inefficiency by sending extra data.

This probably needs deeper look.

Author:	wfurt
Assignees:	-
Labels:	area-System.Net.Quic, tenet-performance
Milestone:	-

[geoffkizer]

This seems a bit complex because the QuicBuffer could be really large, right? Say it's 64K, we consume 32K of it... it might be worth it to inform msquic that we consumed 32K so it can inform the peer and receive more data.

[wfurt]

I'm wondering if we can get more than UDP packet ... or perhaps few. And if few, would that be split to multiple buffers to avoid allocations. Anyway, this looks like something to look into in future.

[karelz]

Triage: Would show up when user reads smaller chunks of data (due to their protocol).
We might punt it to Future.

[CarnaViire]

Fixed in #71969