Working with servers behind a NAT or on a local network (aka "p2p")

[pthatcher]

I've having an increasing number of people asking me for a "p2p" solution for WebTransport. As I've investigated why, and I have found that some people want to run a client/server pair on a common network (where using mDNS for discovery, like WebRTC does, could make sense), and others are running a server behind a NAT, and the easiest solution for them is to use p2p tech like ICE, but other NAT traversal technique may work (for example NAT-PMP or UPnP).

Meanwhile, there is a lot of discussion in the IETF about NAT traversal and p2p QUIC, even without ICE.

What should our approach be for WebTransport on these fronts that are "p2p"?

[jan-ivar]

Meeting:

• Is this addressed by serverCertificates API? If your use case is you have a server on LAN with custom cert.
• Seems half of the solution at least
• Other half is the network part: With WebRTC you can do mDNS discovery.
• Could WebRTC (or new IceTransport) be used to bootstrap a WebTransport connection?
• Exposing mDNS to actual IPs would be a fingerprinting leak
• Cleaner way would be to separate out IceTransport

[jan-ivar]

I wonder are mDNS addresses extracted from WebRTC usable in other web platform APIs already? If user agents support this already then could this be polyfilled?

[jan-ivar]

Could WebRTC (or new IceTransport) be used to bootstrap a WebTransport connection?

WebTransport's lack of p2p came up in today's WebRTC interim meeting proposing a third API for p2p real-time use cases.

If these sound like problems worthy of solutions in WebTransport as well, then it might be timely to consider what's beyond 1.0, so we don't end up solving the same problems twice.

[jan-ivar]

We could do QUIC over ICE. The advantage of QUIC (versus some new raw p2p DTLS transport) is we have CC and flow control wired up already.

I suspect all the API we'd need (with the bulk of the work landing on JSEP to describe how to negotiate QUIC over ICE in SDP):

const pc = new RTCPeerConnection();
const wt = pc.createWebTransport(options);
pc.onnegotiationneeded = () => { /* existing webrtc signaling */ };
pc.onicecandidate = () => { /* existing trickle ICE exchange over signaling */ };
await wt.ready;

Web developers get the same WebTransport surface, with nothing to relearn. It just skips the constructor (and fetch).

There might of course be all sorts of subtle implications here since the other side is no longer a server (no way for drain to happen for example). But broadly speaking most other API stuff seems quite symmetrical.

[marten-seemann]

This could be an interesting use case for p2p QUIC: https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/. This draft has been on hold for a while since we didn't have a use case to drive the design forward, but if there's interest from the WebTransport side, this would be a good reason to revive it.

I also wrote up a blog post outling the vision for p2p QUIC a while ago.

[wilaw]

Meeting -

1. JIB mentioned ideal scenario would be that we address this a year after client-server spec is released and in production and battle tested. We can then extend it to p2p applications.
2. Support from Harald, Randell and Will.
3. Decision to add to Future Version milestone, leave issue open but stop discussing for v1.