WebRTC Spec Questions - 'How STUN can minimize latency', 'non BUNDLE-aware criteria' and 'option to use reuse ICE candidates'

Hi all,

Going through the latest published version of the WebRTC W3C working draft, some questions emerged that I would like to request for clarification. 

Since I haven’t had the opportunity to introduce myself, let me do that first. I’m David, I’ve a background in communication networks and P2P systems, I’m part of Protocol Labs team(http://ipn.io/ <http://ipn.io/>) and currently working on the IPFS project(http://ipfs.io/ <http://ipfs.io/>). We are interested in being close to the WebRTC WG, learn from the work that has been done creating this specification and expose how WebRTC solved some of the key obstacles that are transversal to P2P applications, while at the same time, providing our input, which we hope we can bring some value. I’ve already had the opportunity to talk with Dominique and Vivien and learn how best to follow and contribute to the WG.

Back to the questions, these are:

http://www.w3.org/TR/webrtc/#dictionary-rtciceserver-members <http://www.w3.org/TR/webrtc/#dictionary-rtciceserver-members>
it is desirable to have a STUN server between every layer of NATs in addition to the TURN servers to minimize the peer to peer network latency.

I’m not sure if I understand why a STUN server can minimize latency in a multi NAT scenario.

http://www.w3.org/TR/webrtc/#rtcbundlepolicy-enum <http://www.w3.org/TR/webrtc/#rtcbundlepolicy-enum>
If the remote endpoint is not BUNDLE-aware, negotiate only one audio and video track on separate transports.

What is the criteria, for non BUNDLE-aware clients, to establish only one audio and video track only why is this considered a ‘balanced’ policy?

Also, is there any ICE candidates reuse, specially the non relay ones? One thing that we learned with building libp2p (the network stack of IPFS) is that we can leverage very cheap NAT hole punching by using reusing ports (e.g with TCP REUSEPORT) and executing the protocol multiplexing in userspace.

Thank you.

Best regards,
David Dias
http://daviddias.me/ <http://daviddias.me/>