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

Metrics collection for Hole Punching #1047

Closed
aarshkshah1992 opened this issue Feb 3, 2021 · 3 comments
Closed

Metrics collection for Hole Punching #1047

aarshkshah1992 opened this issue Feb 3, 2021 · 3 comments
Assignees

Comments

@aarshkshah1992
Copy link
Contributor

aarshkshah1992 commented Feb 3, 2021

Once our hole punching endeavour is in decent shape(#1039) . we should put some metrics collection code in there to measure some important stats in the wild before we distribute it to a limited group of users. Some example stats include:

  • Percentage of Symmetric NATs for TCP & UDP.
  • Error percentage on Cone NATs for TCP & UDP.
  • Hole Punch times for TCP & UDP.
  • Bandwidth consumption on Relay servers for co-ordinating the Hole Punch.

This will help us get a better idea if there's parts of the code we can fix/optimize and understand the effectiveness of the endeavour.

@aarshkshah1992
Copy link
Contributor Author

@willscott @jacobheun

Inviting ideas on how to collect these stats in a "centralized" data store which we can inspect later.

@willscott
Copy link
Contributor

A couple options we can think about:

  • we could have nodes express their inferred Nat status as an advertised 'protocol' they speak. That would then allow that to show up in negotiations when they connect to peers, and we can have a node we run in the DHT track the relative prevalence of connecting peers to get a sense of different behaviors.

  • we can add log messges of that, and track the logs of the nodes we run - this isn't representative of the larger IPFS user population though.

AFAIK we don't have ipfs nodes report back telemetry, in a centralized way, and I'm against adding that. This is a decentralized system, and shouldn't have reliance on centralized systems like that.

@marten-seemann
Copy link
Contributor

This is now tracked in libp2p/specs#370.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants