Network Health

While on a Tuple call, you can learn more about the connection between you and the other call participants in the by clicking on the bar icon to the right of your Avatar images:

If you're noticing call degradation on your Tuple call, these metrics can point to steps to improve the call quality.

IN THIS ARTICLE

Bandwidth Usage

Calls are dependent upon the network bandwidth available to Tuple. To prevent network congestion, Tuple has a bandwidth estimation algorithm that determines the amount of bandwidth available for each peer throughout the call. This algorithm is particularly sensitive to perceived packet loss, and higher round-trip times between peers, and will set a much lower cap if it detects either. 

Upload bandwidth - This is your amount of send bandwidth budgeted by our bandwidth estimation algorithm. It caps out at 10mbps, and will be lower (~100-500kbps) if you're sharing audio only.

This estimation can be improved by taking steps to improve your network capacity such as:

1. Use a hardwired ethernet connection. The bandwidth estimation algorithm is sensitive to fluctuations in available network, which are much more common on WiFi.
2. Eliminate other bandwidth hungry applications/processes running alongside Tuple. If you are on a mac, you can get an idea of what's using bandwidth on your computer in Network tab of the built-in macOS Activity Monitor app. A few examples of bandwidth competitors are:
   • An automated background sync job that uploads a back up of your computer to the cloud.
   • A package download manager (for example Cocoapods) downloading multiple packages.
   • A local webserver flooding your local network with traffic.
3. Remove or avoid bandwidth users on your Network. Bandwidth drops are often caused by other people or devices using the same Wifi network. You should be able to get an idea of what's using your entire network bandwidth (if you have other people or devices on your network) by visiting your router's settings page.
4. Quitting unused applications. Other applications on your computer can ask your wireless card to poll the nearby networks, causing it to go into “polling mode.” In this mode, it will spend less time transmitting data which causes network delays that can cause video to stutter or freeze for a few seconds.
   1. To better identify these applications, if you are on a mac you can use the built in macOS Wireless Diagnostics application. Open the Window tab from the mac menu, then select Logs. Enable background wifi logging, hit "refresh," then run `tail /var/log/wifi.log | grep 'SCAN request'` in console to get a list of PIDs requesting scans.

If you're on a low quality network connection, and using 100 percent of your Upload bandwidth, you can take the following steps to reduce the amount of bandwidth used:

1. Set a lower stream resolution and or webcam resolution to reduce the number of bits being sent and hopefully reduce local congestion.
2. Pick either screen sharing or webcam sharing instead of both at the same time to reduce bits being sent and avoid congestion.
3. Drop your system resolution before your call. This tip is particularly salient if your guest has a much smaller screen than you. If you're on a 5K iMac and they're on a 12" Macbook, not only will sending that many pixels cause higher latency, but the text on your guest's side will be near-unreadable.

Download bandwidth - This is your amount of download bandwidth budgeted by our bandwidth estimation algorithm.

Active VPN

This diagnostic is only shown to you if Tuple detects that you are on a VPN.

Given Tuple calls are peer-to-peer connections (as opposed to an intermediate server like Zoom), quality can be affected by how the call was routed through the internet. VPNs or particularly strict firewalls can cause calls to be routed very inefficiently depending on the settings.

If you notice call degradation while using a VPN, we suggest trying a call off of the VPN to see if call quality improves. If you see an improvement, we suggest reaching out to whomever configures the VPN to adjust the settings, or not using the VPN while you are on calls. Read more about troubleshooting your VPN setup here.

Round-trip times

This metric is the amount of time it takes for a packet to get from one user to another and back. As Tuple calls are peer-to-peer connections (and do not go through an intermediate server), this metric reflects the travel time for the connection between you and the other call participants. If your call has multiple participants, you will see separate round-trip times for the time it takes a packet to reach each individual call participant and then return to you.

Generally, unless you are doing a very long distance call (Sydney, Australia to NYC, USA for example) round-trip times should be 100ms or less. Higher round-trip times are usually caused by one of the following:

1. Network queues building up causing congestion. WiFi congestion is the most likely, but congestion can occur in any network device (see Use A Wired Ethernet connection below).
2. A bandwidth hungry app/process is occurring alongside the Tuple call causing congestion. which means probes sent to measure round-trip will be queued.
3. Packets taking a very inefficient route through the internet between peers. This can happen if you are on a VPN that is routing your traffic inefficiently (see Active VPN above).
4. Traffic being routed via TURN servers (see Connection Type below).
5. CPU usage related lag delaying round-trip probe cycles.

Packet loss

Packet loss happens when packets of data traveling across a network connection fail to reach their destination. In most cases, it's caused by errors in data transmission across WiFi networks (see  Use A Wired Ethernet connection below), or by network congestion, but can also be caused by errors in data transmission at the ISP level. Packet loss numbers can often be improved by restarting your router, and moving closer to it.

Packet loss values are shown for each other peer on the call. These values are calculated by a true-up of how many packets this specific peer's client sent to you, versus how many you have actually received from the peer's client.

Packets can be lost anywhere along the connection between you and your peer, and the fault can be on either end. To determine where you're losing packets, you can perform a ping test:

Diagnosing Packet Loss

Since Tuple calls are peer-to peer connections, you can `traceroute` your pair's IP address in terminal to check for latency at each hop between you and your peer:

`traceroute 192.168.0.1` (Replace this IP with your peer's IP address)

If you see response times greater that 100ms for a hop, that can indicate where latency/congestion is being introduced into the connection, and may be where packets are being lost.

You can also use `ping` to discover where you're losing packets. While your Tuple connection is running:

1. Check for packet loss between router (note: this is likely your router's IP but it may be different) and your computer: `ping 192.168.0.1 -c 50` 
2. Check for packet loss between your computer and an arbitrary site: `ping google.com -c 50` 
3. Check for packet loss between you and your pair: `ping [their public IP address] -c 50`

If this still doesn't uncover a particular place where packets are being dropped, you can get some more detailed diagnostics by using: `netstat -s` which will show you a packet loss breakdown by packet type. 

Once you have identified where packets are being lost, you can take steps to mitigate loss. You may need to move closer to your router, re-configure VPN or firewall settings, or even call your ISP and tell them that one of their servers is dropping packets — they can re-route your connection through a more stable path.

Use a wired Ethernet connection

Using a wired Ethernet connection reduces packet loss significantly which can really improve Tuple's performance. WiFi setups can be quite noisy and introduce a lot of local packet loss. Tuple has a congestion control algorithm that is heavily based on packet loss which can decrease the performance.

If you can't use an ethernet connection, make sure you are as close as possible to the WiFi access point. If you're nearby other WiFi networks, you might be competing on the same channel which can lead to dropped packets. Depending on your router software, you may be able to manually change to a different channel which might not be as crowded.

Connection Type

When it's not possible to obtain a peer-to-peer connection through local or public networks, Tuple uses Twilio to route media data through TURN servers. 

If you see a "No" appear here, your connection is not peer-to-peer.

There is no way to force your connection to be peer-to-peer, but you can take steps to allow peer-to-peer connections to be made. Tuple will only fall back to non peer-to-peer connections if all possible connection types are blocked, and there are a few things that could be blocking your connection:

1. Firewalls - Depending on the configuration of your firewalls, peer-to-peer traffic may be blocked.
2. VPN - Depending on the configuration of your VPN, certain connection types may be blocked.
3. Router - Your configurations may cause certain connection types to be blocked.
4. Your ISP - Certain internet providers attempt to slow down specific types of traffic. At times the ISP might throttle your traffic, and block certain types of connections.