"SendableFrames was SendableFrames { acks: false, other: true }, but only ACKs have been written" #1850
Comments
|
Thanks for the report! This indicates that Are you transmitting large application datagrams on the endpoint where this panic occurs? If so, #1837 is a likely culprit. In particular I wonder if 003b1d5 or ad4919b might be responsible. I can think of at least one likely broken pattern:
In short, I think the actual behavior here is correct, and we should arrange for the assert not to fire, either by relaxing the assert somehow or by allowing I'll try to draft a fix for at least that case this week, though more info is needed from you to provide confidence that this is specifically what you're hitting. Do you have a consistent repro? |
|
On second thought, I suspect the issue I described above predates #1837, though if that's not what you're experiencing then it's still a plausible culprit. |
|
Drafted some related cleanup in #1851. Testing indicates that the hypothesis I presented above is incorrect; we already handled that case properly, so I remain unsure what the root cause might be. I don't expect that PR will fix your issue, though it makes some of the code involved easier to follow. Let us know if you have a repro, and I'll look around a little more for other possible causes. |
Yes, I am. (Independently of this issue, it seems
We usually run our tests with all the offloading features disabled with Unfortunately, #1851 does not fix the issue. The attached patch deterministically triggers the bug for me. If the server wants to send just 10 datagrams instead of the current 100, then the panic does not occur. 0001-Modify-example-to-demostrate-bug-1850.patch.txt (I think it would be helpful if the repository contained a datagram example. It took me a long time to figure out a way to keep the connection alive until an ApplicationClosed arrives. I'm happy to contribute, but I cannot come up with a good example. Maybe a simple file transfer with datagrams?) |
|
Thanks for the repro! I see the same behavior. I'll investigate. As a temporary workaround, it looks like sending smaller datagrams avoids the assert, probably by leaving enough room for whatever other frames are competing for space in the packet. 1KiB would be a very safe threshold.
Did you see |
|
This will be fixed by #1854. |
I confirm this problem disappeared with the git HEAD. Thank you.
I don't know what I was thinking. I didn't checked the documentation :( It is clear and easy to understand. Concerning the current solution, if I understand correctly, then applications are better off sending smaller datagrams than |
Note you can just upgrade your dependencies with |
Right, that works against the grain of the protocol. What were you trying to achieve with using datagrams in this design? |
We try to optimize media transmission in different network environments. Our baseline is RTP/UDP. It would be good to see how QUIC performs in comparison to the baseline when both use unreliable transmission. We also measure when the media is transmitted in QUIC streams. |
The intention is that these voluntary ACKs are sent infrequently enough for this not to be a significant factor. If you observe it imposing meaningful costs in practice, we have a lot of room to dial the rate further, too.
I don't think so. Most packets do not include extra control frames, and packet scheduling and assembly is only loosely bound to application call patterns. The only cases where a call like this would give you accurate information is when you're only sending one packet at a time, without any pipelining or queuing, which is exactly when overhead matters the least. Otherwise, it's difficult to be confident that the datagrams you queue will, in fact, be in the next packet scent.
Real-time streaming media is a complex case. Using a stream gives the QUIC implementation much more flexibility in packet assembly, but is subject to head-of-line blocking, which I presume you wish to avoid. A good middle ground might be to use many independent streams and take care that your receiver is willing to read them concurrently/out-of-order, where each stream is a data unit that's not useful unless received in full. You could even reset such streams when they become too old, though that may not be worth the effort. |
I get the backtrace below using the latest commit 1e54758. Can you, please, tell me how should I debug the issue? Thanks.
The text was updated successfully, but these errors were encountered: