Skip to content

Streams may enter an unresponsive state due to "Fragment MTU exceeded" #6126

Description

@jianye-chen

Describe the bug

Under some network conditions, streams may become unresponsive while connection remains intact.
After dropping the connection by an application level timeout, newly established connections may recover.

[0]8568.6468::2026/06/24-05:22:28.171623600 [Microsoft-Quic][C][TX][233] SH DestCid:70845077534919afd6 KP:0 SB:1 (Payload 1446 bytes)
[0]8568.6468::2026/06/24-05:22:28.171626500 [Microsoft-Quic][C][TX][233]   PING
[0]8568.6468::2026/06/24-05:22:28.171629300 [Microsoft-Quic][C][TX][233]   STREAM ID:292 Offset:0 Len:192 Fin
[0]8568.6468::2026/06/24-05:22:28.171633300 [Microsoft-Quic][C][TX][233]   PADDING Len:1244

Reason = 258(Fragment MTU exceeded). Direction = 0(Send). NBL = 0xFFFFC88FD3EDAA80.
[0]8568.6468::2026/06/24-05:22:28.171720000 [Microsoft-Windows-Winsock-AFD]sendmsg: 1: Process 0xFFFFC88FDB042200, Endpoint 0xFFFFC88FBE074010, Buffer Count 1, Buffer 0xFFFFC88F887D2190, Length 1472, Seq 3045, Status 0xC0000206(NT=The size of the buffer is invalid for the specified operation.)

[0]8568.6468::2026/06/24-05:22:28.171732400 [Microsoft-Quic][data][0x11F88429710] ERROR, 1784, WSASendMsg completion.

Workaround

Set QuicSettings.MinimumMtu and QuicSettings.MaximumMtu to a constant value 1248.

Affected OS

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

Additional OS information

No response

MsQuic version

v2.5.6

Steps taken to reproduce bug

  1. establish a connection
  2. create a stream
  3. send some data

Expected behavior

Streams should eventually deliver all data enqueued.

Actual outcome

Streams enter an unresponsive state and stop delivering any data.

Additional details

No response

Metadata

Metadata

Assignees

Labels

Area: CoreRelated to the shared, core protocol logic

Type

Projects

Status
No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions