Hacker News Reader

Comment by AlexAltea | Hacker News Reader

I can't blame them either... but isn't high bandwidth usage a solvable problem?

Why can't they switch to P2P audio/video transmission instead of funneling everything through their servers?

The key issue with P2P is that you have many more total connections in the system, so the service itself usually takes a hit. You get N^2 in stead of N streams. You can also easier optimize the video quality per peer with a centralized system, possibly saving even further amounts of streams, because (as an example) you don't have to send out a 120p + 240p + 480p + 720p and so on, you only need to send one 720p stream, however this could conceivably be solved by smart compression. With p2p you would have to send the same stream to all participants. It becomes impractical very fast, and the quality of the service goes down quickly.

You do get worse latency though, right? Which I believe to be important for conversation quality, even when users don’t actively realize that latency is to blame.

I’ve always felt that Skype calls became much worse once Microsoft bought them and shifted away from p2p.

> You do get worse latency though, right? Which I believe to be important for conversation quality, even when users don’t actively realize that latency is to blame.

Latency in voice communication is super important, yes.

P2P latency can be better or worse than P2S2P latency. It depends on the networks the peers and server are on, where all parties are located, and how they're interconnected.

If the peers are on the same ISP, P2P is probably better, if they're not, it can vary widely. Sometimes those ISP will exchange packets directly, but far away, whereas they both may have more direct routes to a nearby server. If the peers are far away, the server network may have better long distance transit than the peer ISPs. Of course, sometimes the server is far away from both the peers. For some participants, p2p brings problems because it exposes each peer's IP to the other peers.

A well designed system will measure and adjust the routing for the best results, including during the call (and carefully adjust the buffering to avoid large jitter) as conditions can change.

I’d say 50% or more of my zoom calls involve 2 or fewer other people all on decent (>20mbps) connections. P2P seems viable for a large chunk of the usage where N is small.

You might be surprised how little of the "sticker bandwidth" on a residential connection you can actually use when you are sending UDP at a highish packet rate, perhaps to an international destination, and need low loss+latency+jitter.

The average experience of users would go down significantly as you start to multiply the bandwidth requirements, which is why P2P isn't typically used for more than 2 participants despite the potential bandwidth savings to the operator.

I suspect the support costs and adoption friction for bypassing all possible consumer NAT devices would be high. (No one wants to get the reputation as “oh, that video conf software fails to work a lot”.)

I suppose “try the P2P method and fallback automatically/invisibly to server-connected if that fails” could work pretty well though.

> (No one wants to get the reputation as “oh, that video conf software fails to work a lot”.)

Webex seem happy

Doesn't STUN/TURN effectively deal with the NAT problem nowadays, or is there more to it than that?

When you can't establish a direct connection (potentially with the help of STUN), you need to use TURN, which uses a server as a relay, so it's not really P2P any more (although a TURN server does less work than an SFU, so you can scale it up more cheaply).

Because P2P doesn't scale well when you have tens or hundreds of people transmitting video and consuming the video on different devices (mobile vs desktop) across different regions. You can't guarantee the experience is good when you don't control the distribution. Also P2P had potential to expose user IP's

Reply on news.ycombinator.com