What does ConnBlockedByAmplificationProtUs mean?

[murphypei]

I send 100M bytes (1M bytes per send) on a wireless network, the server send complete but the client receive nothing. but it will not happen on the same wired network. I notice the ConnBlockedByAmplificationProtUs in the statistics of the stream is too large, but it has no documentation, so what should I try to figure it out? Any suggestion will be help, thanks.

CorrelationId: 1                 
VersionNegotiation: 0          
StatelessRetry: 0            
ResumptionAttempted: 0                                                                                                                                                                            
ResumptionSucceeded: 0                                                                                                                                                                            
GreaseBitNegotiated: 0                                                                                                                                                                            
EcnCapable: 0                                                                                                                                                                                     
RESERVED: 0                                                                                                                                                                                       
MinRtt: 3298    
Rtt: 4849 
MaxRtt: 5071                     
TimingStart: 1649139062        
TimingInitialFlightEnd: 1649147363
TimingHandshakeFlightEnd: 1650180341
HandshakeClientFlight1Bytes: 271
HandshakeServerFlight1Bytes: 1514
HandshakeClientFlight2Bytes: 52
SendPathMtu: 1500    
SendTotalPackets: 34       
SendRetransmittablePackets: 26
SendSuspectedLostPackets: 2     
SendSpuriousLostPackets: 0
SendTotalBytes: 38100  
SendTotalStreamBytes: 25978
SendCongestionCount: 1 
SendPersistentCongestionCount: 0
RecvTotalPackets: 14
RecvReorderedPackets: 0
RecvDroppedPackets: 1    
RecvDuplicatePackets: 0
RecvTotalBytes: 10621
RecvTotalPackets: 14      
RecvTotalStreamBytes: 6
RecvDecryptionFailures: 0
RecvValidAckFrames: 7                                                                                                                                                                             
KeyUpdateCount: 0           
SendCongestionWindow: 5888
DestCidUpdateCount: 0                                                                       
SendEcnCongestionCount: 0    

ConnBlockedBySchedulingUs: 0     
ConnBlockedByPacingUs: 0       
ConnBlockedByAmplificationProtUs: 18446744072059400391                                      
ConnBlockedByCongestionControlUs: 10446743                                                                                                                                                        
ConnBlockedByFlowControlUs: 0                                                                                                                                                                     
StreamBlockedByIdFlowControlUs: 0
StreamBlockedByFlowControlUs: 0
StreamBlockedByAppUs: 1131018

[murphypei]

Update: I split the send data to 1200 bytes (< MTU), then I can receive the data of the front few packets, and I can't receive any QUIC_STREAM_EVENT_RECEIVE.

[nibanks]

Amplification protection is logic that limits the server from sending more that 3 times what it has received from the client before it has been able to validate IP address ownership of the client. But that number you show above looks like an uninitialized value. Did the handshake succeed?

[murphypei]

But that number you show above looks like an uninitialized value.

Yes, I have checked it, you're right.

Did the handshake succeed.

I have checked my logs, all of the sending were sent after the event QUIC_CONNECTION_EVENT_CONNECTED, should I think it means the handshake was complete?

And I collected stream statistics again.

ConnBlockedBySchedulingUs: 0                                 
ConnBlockedByPacingUs: 0                                                                                                                                                                                                                                                         
ConnBlockedByAmplificationProtUs: 0                                                                                                                                                                                                                                              
ConnBlockedByCongestionControlUs: 12136163                                                                                                                                                                                                                                       
ConnBlockedByFlowControlUs: 0                                                                                                                                                                                                                                                    
StreamBlockedByIdFlowControlUs: 10609                                                                                                                                                                                                                                            
StreamBlockedByFlowControlUs: 10607                          
StreamBlockedByAppUs: 102577  

It seems that congestion control is too large.

If I change the StreamSend buffer size to 1000 bytes, the sending and receiving work fine. So I guess is it that the network card can't handle too much sending data? Then I change the sending size to 2000 but sleep 2s after sending, the issue remains. And I have noticed the stream will be closed because idle timeout(idle timeout is set to 10s). So I think maybe the MsQUIC doesn't submit the sending task. The network card watcher also shows it is free.The socket TCP and UDP sending works fine on the wireless network.
So I think is there any strategy that may make it impossible to send data when the wireless network is connected?