The Latency of the First Frame is Too High

[AvatarGanymede]

Hi, sorry to interrupt again. 😌
I'm working on a project and the work flow is as below:

Server: Captures desktrop and Sends it through Quic Stream
Client: 
            case QUIC_STREAM_EVENT_RECEIVE:
                    copy QUIC Buffer and Push the copied data for the process on the other thread

I've known that MsQuic internally seperates my captured frame into a few small packets, so I add a header flag ahead of the frame data:

---------------------------------------
|| header | frame || header | frame ||
---------------------------------------

Thus I know where the frame data ends on client side and assemble these small packets into a complete frame.
Then I try to test the time cost of each frame, from receiving the first packet to the last packet:

It's obvious that, the length of these frame data is close, but the latency of the first frame is way too high.

StreamOpen(Connection, QUIC_STREAM_OPEN_FLAG_0_RTT, ServerStreamCallback, this, &m_stream);
...
StreamStart(m_stream, QUIC_STREAM_START_FLAG_ASYNC | QUIC_STREAM_START_FLAG_IMMEDIATE);
...
StreamSend(m_stream, m_sendBuffer, 1, QUIC_SEND_FLAG_ALLOW_0_RTT, m_sendBuffer)

Do I Miss some crutial setting or using something wrong?

[nibanks]

Is this first payload the first one the whole connection? I suspect the connection handshake is what is taking so long the first time around.

[nibanks]

If you're sending it after that, then the handshake should be complete. Can you grab logs and share them out?

[AvatarGanymede]

log.zip
Server is sending side and Client is receiveing side.
The 'QUIC Excution' Window of the Client is as below:

No.19 TimeAckDelay seems quite time-consuming.

[nibanks]

Ah, so you're saying the delayed ACK might be involved here? Exactly when do you stop your time measurement, for the data above? When you receive the FIN / peer shutdown notification? Or when you get shutdown complete?

[AvatarGanymede]

I measure the time, from I receive the header of the frame, to the end of the frame. All the thing is done after the client receives QUIC_STREAM_EVENT_RECEIVE.
The stream never shuts donw until the last frame has been sent.

[chunlei-wu]

I send the first payload after the Event QUIC_CONNECTION_EVENT_CONNECTED is triggered. In the doc, this Event means that the handshake has completed.

Hi AatarGanymede,

Do you find the root cause and solution now? I want to learn it, many thanks.