What is Snowflake?

Snowflake is a proposal to extend the ICE protocol that is still ongoing. It’s main goal is to allow endpoints to establish connectivity more quickly between each other.

ICE enforces stringent global pacing requirements, couples timing dependencies between ICE agents, and requires checks to be successful in both directions. At the WebRTC NV meeting last week, we discussed the evolution of ICE. Specifically, we contemplated adding more flexibility to ICE. The Snowflake proposal is designed to provide a more flexible system that would address some of the inflexibilities of ICE candidate gathering (ordering and reordering candidates), ICE candidate pacing (timing and duration of ICE checks), and other features.

Similar to ICE, both endpoints gather address candidates that may work for communication. However, with Snowflake, the sender endpoint sends STUN Connectivity Check packets to wherever the receiver endpoint specifies, whenever it specifies. In the current proposal, the receiver endpoint is responsible for deciding the algorithm for sorting the local ICE candidates and timing checks to find the optimal path.

Snowflake Use Case Example

For example, Alice is using a multihomed tablet to collaborate with Bob, who is on mobile. Alice wants to receive high resolution (1080p) media because her screen size is large, while Bob is fine with lower resolution (480p) video. To solve this so both are happy, Alice could use asymmetric paths for sending and receiving video using the multihoming of her tablet, WiFi and 3G/LTE. She would use the 3G/LTE for sending her media stream and use WiFi to receive the media stream. Meanwhile, Bob might prefer to send and receive media streams over their 3G/LTE interface. This would not be possible without the Snowflake extension to ICE.

Components of Snowflake

Several different components go into the Snowflake architecture, including the endpoints (sender endpoint and receiver endpoint), the snowflake agent, CallAgent, STUN server, and the TURN Server/Media Router.

Sender and Receiver Endpoint

The sender endpoint is an endpoint that sends data streams to a remote endpoint. It is a snowflake agent. Consequently, a receiver endpoint is an endpoint that receives data streams.

Snowflake Agent

A snowflake agent is a software agent that implements a STUN Client implementation for, at minimum, gathering candidates and performing connectivity checks.

CallAgent

The CallAgent is a publicly reachable server that the sender endpoint and receiver endpoints may both access. It creates a channel or message bus to carry protocol messages such as signals/intentions between different Snowflake agents. This is a new component in the proposal, and its functionality will evolve as the proposal is discussed further.

STUN Server

The STUN Server is an optional server in the Snowflake protocol that is inherited from ICE. It is responsible for exposing the public-facing transport address of an endpoint behind NAT to the endpoint.

TURN Server/Media Router

The TURN Server/Media Router is the media relay between different endpoints when the endpoint is behind a very aggressive NAT/Firewall.

The Protocol

With Snowflake, each receiver endpoint needs to find a viable path for incoming media. In order to accomplish this, each receiver endpoint specifies the addresses for the sender endpoint to verify connectivity. The sender endpoint is then able to transmit media once a usable path has been settled.

These are the steps associated with the Snowflake Protocol.

1. A channel is established between the endpoints that is used to exchange protocol control messages.
2. The sender endpoint notifies the receiver endpoint using the channel with a PlaceCall control message populated with ICE candidates. This notifies the receiver endpoint that it is prepared to send media.
3. Once the receiver endpoint has received the sender endpoint’s intention, it assembles its own ICE candidates and re-sorts them based on the success of previous checks, local policies, or based on guidance from AI/ML algorithms.
4. The receiver endpoint notifies the sender endpoint that it should carry out STUN connectivity checks using the channel with a DoPing control message. This message includes the candidate pair the sender endpoint needs to detect the reachability to the receiver endpoint.
5. The receiver endpoint can send as many DoPing messages per candidate pair to the sender endpoint as it wants to be tested for connectivity. The order, timing, and number of candidate pairs to be tested are dependent on the receiver endpoint implementation.
6. The sender endpoint receives the DoPing message that includes the candidate pair. The sender endpoint completes STUN ping checks on the candidate pair by sending the STUN Binding Request message toward the receiver endpoint over the media path. This opens up the necessary local pinholes, which are maintained for the entirety of the session by the sender endpoint. The frequency and timing of the STUN ping checks is dependent on the congestion control requirements for the underlying transport.
7. The receiver endpoint receives the STUN Ping from the sender endpoint. It then does two things:
   • The receiver endpoint sends a STUN Binding Response.
   • The receiver endpoint sends a GotPing control message using the channel with details from the STUN Binding Response. The sender endpoint uses this to verify the connectivity status results using the channel.
8. If the STUN Ping response is received, the sender endpoint has a feasible path to transmit media.

These eight steps may be executed regularly during the entirety of the session, dependent on when the receiver endpoint identifies better candidates to receive media. This is based on local policies.

Advantages of Snowflake

Diagnostics

Snowflake simplifies identifying which outbound connections are sent from the sender endpoint to open a pin hole. Connectivity can be verified simply once the sender endpoint requests the receiver endpoint send a test STUN Ping. Furthermore, a client can easily have an automated test framework that tests receiving and sending capability independently.

Timing

Snowflake drastically reduces and in some cases completely removes the timing complexity. Both endpoints are responsible for their own timing.

---

This article expands on a previous article we have written delving into the evolution of the WebRTC ICE API. The WebRTC Working Group met last week to discuss the evolution of the WebRTC v1.0 spec based on emerging use-cases and developer feedback on the current API. Check out our post to learn more about ICE.

---