IPv6 with IPv4 fast fallback (RFC 6555) for RTMP by jgh-twitch · Pull Request #9120 · obsproject/obs-studio (original) (raw)

Description

This PR changes the RTMP connection behavior from preferring IPv4 when it is available to attempting the user's operating system's preference first followed by the other address family using the algorithm described in RFC 6555. In practice, unless the user has changed the OS configuration, this means that IPv6 will be attempted first. After the initial connection attempt the algorithm will wait 200ms before attempting an address from the other family (usually IPv4). The first TCP connection that is established is the winner and all other attempts are closed.

I have broken this PR up into three commits for review:

• b4b5f27 Adds the happy eyeballs algorithm itself
• 2be2ee7 Adopts the happy eyeballs component into librtmp by replacing the existing connection logic.
• 9805459 Adds an option in Settings -> Advanced for the user to change the behavior of this algorithm (IPv4+IPv6, IPv4-Only, IPv6-Only)

Why not RFC 8305?

After reviewing RFC 8305 it seems that the simple algorithm described is compatible with RFC 6555 and the additional recommendations are optimizations. For the sake of keeping things simple for now I decided to stick with RFC 6555 and if in the future further optimizations are warranted RFC 8305 can be adopted.

Motivation and Context

The motivation behind this PR is that in many international markets ISPs are increasingly IPv6-Native. Using IPv4-only devices or accessing IPv4-only services requires going through additional translation layers. These translation layers such as 464XLAT or NAT64 can contribute to higher round trip times, packet loss, and ingest starvation. Dual-stack users will therefore benefit from preferring IPv6 in order to avoid these translation layers where possible.

How Has This Been Tested?

I have tested these changes on Windows 10 (Dell XPS laptop), MacOS 13.4 (MBP 16" Core i9), Ubuntu Jammy (Dell XPS Laptop+Virtualbox). Tests were run on T-Mobile's IPv6-native network with 464XLAT CGNAT and Google Fiber.

I tested various combinations of IPv4 and IPv6 availability as well as IPv4-only networks. Additionally I was able to test a broken CGNAT that was breaking the TCP handshake on IPv6, resulting in successful fallback to IPv4.

I don't think I will be able to test all of the creative ways that ISPs can mess up their IPv6 deployments, but it seems to work as expected in the scenarios I was able to test. In cases where it does not work users will have the ability to change their settings to use IPv4-only as before.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.