Incomplete data packets received when encryption is disable.

[fofewyoung]

Describe the bug

In my stress testing program, when I turn off encryption by setting QUIC_PARAM_CONN_DISABLE_1RTT_ENCRYPTION to TRUE, I found that there is a small chance of receiving incomplete data packets (some header bytes is missing).

Affected OS

• Windows
• Linux
• macOS
• Other (specify below)

Additional OS information

windows 10

MsQuic version

release/2.1

Steps taken to reproduce bug

1. set QUIC_PARAM_CONN_DISABLE_1RTT_ENCRYPTION to TRUE
2. send many packets to clients from one server
3. use clumsy to make some lag and drop
4. Verifying data integrity

Expected behavior

Receiving complete data packets

Actual outcome

some header bytes is missing

Additional details

No response

[nibanks]

small chance of receiving incomplete data packets

Can you please provide more details on this? What do you mean by incomplete? Just not all in a single receive call? It never comes? Do you have any logs you can share?

[fofewyoung]

int my test:
server:
stream send bytes0: 240 240 0 0 0 0 0 1 2 3 4 5 (12 bytes)
stream send bytes1: 240 240 0 0 0 0 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9……(40KB ~ 60KB)
...

client:
stream receive bytes0: 240 240 0 0 0 0 0 1 2 3 4 5 (12 bytes) -- ok
stream receive bytes1: 5 6 7 8 9 1 2 3 4 5 6 7 8 9…… the header bytes(240 240 0 0 0 0 0 1 2 3 4 ) is missing
...

[nibanks]

Can you share logs for a repro?

[fofewyoung]

@nibanks
https://drive.google.com/file/d/16WR2NWT3oO12Y6vtjsCIJYK2ziM-ZMpO/view?usp=share_link

[fofewyoung]

I tested the whole day today with the same code, only the encryption was turned on, and the issue never happened

[nibanks]

The only thing I can think is that the UDP checksum was bad and the packet was still accepted. I think the only way forward here is to add minimal checksum support.