search

cloudflare / quiche

🥧 Savoury implementation of the QUIC transport protocol and HTTP/3
https://docs.quic.tech/quiche/
BSD 2-Clause "Simplified" License
9.45k stars 719 forks source link

Question: how to figure out why tx_cap converges to 0 and does not recover. #1038

Open suhrm opened 3 years ago

suhrm commented 3 years ago

Hi.

I have an application where an mobile robot moves between different wireless access point and using your quic implementation for transport.

during my testing I have experience that both the tx_cap and cwnd in some cases converge to 0. I would expect adjustsments now and then depending on the conditions e.g. handover, interference etc. However what I observe is that sometime it slowly decreases to 0 without recovering and thereby giving and Error 11 I have tried both stream and dgram based transmission and it is the case for both types.

There is ofcourse also the possibility of error in my implementation however I do not observe the same behavior when the robot is static, i.e. not moving.

I have looked at both qlogs and debug output cause but I do not really know what I should be looking for, or if it is even possible to extract from those.

Therefore I was hoping that somebody could point me in the direction on where to look next.

Regards.

LPardue commented 3 years ago

Thanks for the report. Sounds like its something to do with the handover period between access points. Are you using quiche for cllient and server? Are these your own applications that are driving the event timers and socket? It would be useful to see some debug or qlogs to see what is happening.

zhining-lu commented 1 year ago

When I use multiple streams on a quic channel to send data for a long time, sometimes cap=0 occurs and will not be recovered(version is [0.14.0])

zhining-lu commented 1 year ago

When I use multiple streams on a quic channel to send data for a long time, sometimes cap=0 occurs and will not be recovered(version is [0.14.0])

I successfully reproduced this problem. The reason is that the client stream channel is closed, but the server stream channel is not manually closed and the server stream channel keeps writing data. After the write buffer is full, iswritable return false