Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

connections keep switching away from direct connection and switching back #2169

Closed
flub opened this issue Apr 10, 2024 · 4 comments · Fixed by #2238 or #2255
Closed

connections keep switching away from direct connection and switching back #2169

flub opened this issue Apr 10, 2024 · 4 comments · Fixed by #2238 or #2255
Labels
bug Something isn't working c-iroh-net
Milestone

Comments

@flub
Copy link
Contributor

flub commented Apr 10, 2024

On slower connections we noticed we keep switching connections all the time. Even though we would expect them to stay direct. E.g. transcript from a modified iroh doctor:

Accepted connection from fltgqbqd37gta4bvy22zknq62m5xp4rucuijng7ds7up7ixl4daq
connection type changed to: relay
connection type changed to: direct
connection type changed to: mixed
connection type changed to: direct
17.978148733s: rtt: 332.081712ms
connection type changed to: mixed
connection type changed to: direct
connection type changed to: mixed
29.551192275s: rtt: 337.195327ms
connection type changed to: direct
connection type changed to: relay
connection type changed to: direct
connection type changed to: relay
Test finished after 40.893338786s: connection lost
@flub
Copy link
Contributor Author

flub commented Apr 11, 2024

I suspect this is mostly because we have lossy ping/pongs:

... INFO ... iroh_net::magicsock::node_map::best_addr: 87: clearing best_addr reason=PongTimeout has_relay=true old_addr=213.143.125.104:57096

@flub
Copy link
Contributor Author

flub commented Apr 11, 2024

this is a bit silly in a way, because we know there's a lot of traffic flowing around at this point. traffic which is being acked by quic in both directions. We only downgrade the connection because this pong is treated as more important somehow, and missing it forces downgrading our connection even if data is flowing over it.

We might be able to improve this by not considering the loss of a pong so important if other data is flowing as well.

@ramfox
Copy link
Contributor

ramfox commented Apr 11, 2024

Agreed. It seems sort of silly to decide that a connection is dead if we are literally getting UDP packets from that addr at the same time as we timeout on a pong.

@dignifiedquire dignifiedquire modified the milestones: v0.14.0, v0.15.0 Apr 15, 2024
@flub flub changed the title connections keep switching away from direct connection and swithching back connections keep switching away from direct connection and switching back Apr 23, 2024
@dignifiedquire
Copy link
Contributor

unfortunately still happening on main

onnection type changed to: mixed
connection type changed to: direct
connection type changed to: mixed
connection type changed to: direct
connection type changed to: mixed
connection type changed to: direct
connection type changed to: mixed
connection type changed to: direct
connection type changed to: mixed
connection type changed to: direct

@dignifiedquire dignifiedquire modified the milestones: v0.15.0, v0.16.0 Apr 29, 2024
github-merge-queue bot pushed a commit that referenced this issue Apr 30, 2024
When receiving data via UDP, we were not extending the validity of the
current `best_addr`. This would trigger expiry of the `best_addr`, even
though it was actively being used.

This fix, extends the validity, everytime we successfully receive a UDP
packet on the current `best_addr`.

Closes #2169
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment