You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Description
The problem is that while the connection to the relay server is still
being established sent packets are already being dropped while being
queued to send. This means when the connection is finally established
they are not there to be sent and depending on some scheduling luck
connections will often fail. Extending this timeout makes
establishing connections via the relay only much more reliable.
## Breaking Changes
<!-- Optional, if there are any breaking changes document them,
including how to migrate older code. -->
## Notes & open questions
"depending on scheduling luck" is a bit hand-wavy. I would have
expected QUIC to recover from this and re-send the packets. I think
it depends on exactly how long it takes to establish the connection,
re-tries could still end up being dropped in this queue if badly
timed.
It is hard to say if 3*PTO is sufficient. There is an argument for
even longer, but it is a trade-off of blocking the entire relay queue
if it is too long and giving enough time to establish a normal
connection.
## Change checklist
- [x] Self-review.
- [x] Documentation updates following the [style
guide](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text),
if relevant.
- [x] Tests if relevant.
- [x] All breaking changes documented.
0 commit comments