UDP Holepunching with QUICK for more compatiable NAT traversal

[TheRook]

The hole punching documentation stays that DCUtR is being used with TCP:
https://docs.libp2p.io/concepts/nat/hole-punching/

The DCUtR documentation says that it works best with UDP and reasonably well with TCP:
https://github.com/libp2p/specs/blob/master/relay/DCUtR.md

The go-libp2p implementation is not considering the differences in how edge network routers may react to a TCP vs UDP hole-punch:

go-libp2p/p2p/protocol/holepunch/holepuncher.go

Lines 88 to 99 in 58c4cb8

	func (hp *holePuncher) DirectConnect(p peer.ID) error {
	if err := hp.beginDirectConnect(p); err != nil {
	return err
	}
	defer func() {
	hp.activeMx.Lock()
	delete(hp.active, p)
	hp.activeMx.Unlock()
	}()
	return hp.directConnect(p)

Ideally - go-libp2p would try the most efficient method first, which is probably UPnP. If UPnP fails, then try a QUICK with a UDP holepunch to see if can be used to form connection. If this more efficient UDP method fails, then try the current TCP holepunch - if that fails then look for a relay... and if relays are failing then the client is likely being filtered by their ISP or government.

[p-shahi]

Hi, thanks for creating this issue but I will close it since it's better topic for the discussion forum: discuss.libp2p.io

Ideally - go-libp2p would try the most efficient UDP based holepunch - so maybe using QUICK with a UDP to see if that accepts connections - if it fails then try the current TCP holepunch - if that fails then look for a relay.

This is an improvement we've identified. See: #1785

Also, the Probe Lab team recently ran a hole punching measurement campaign and results will be published soon: https://discuss.libp2p.io/t/call-for-participation-nat-hole-punching-measurement-campaign/1690