channeler

Introduction

Channeler is a multi-channel protocol with per-channel capabilities. It’s something of a parallel development to QUIC, but with distinct features.

The design for channeler was originally inspired by experience with video streaming over peer-to-peer networks in 2006-2009. In order to safely traverse NATs, a UDP-based implementation is required. Using that, however, means losing reliability criteria of TCP.

From an application perspective, however, it’s not always clear which is preferred. More precisely, it’s usually the case that for some messages, reliability is a good idea – while for others, it adds unnecessary overhead.

Unlike QUIC, which replicates TCP’s reliability over UDP, in Channeler one can choose the reliability characteristics of every channel individually. Furthermore, there are a lot more choices available than TCP’s ordered mode with resend or UDP’s fire-and-forget mechanisms.

Because NAT traversal is only a concern once for the UDP source and destination tuple, any other channels can still traverse the NAT, if reliability is enabled or not.

Furthermore, transport encryption is part of Channeler’s design. To this end, channeler employs a simple scheme1 based on the Noise Protocol Framework, which explicitly circumvents complexities present in DTLS.

Work on Channeler was partially funded with a grant from NGI Zero.

Dependencies

All of channeler makes use of liberate. Measuring round-trip time in order to make application-level decisions on congestion uses the spin_bit library. Transport encryption makes use of primitives from the s3kr1t library.

The implementation does not make use of sockets or similar mechanisms directly, and thus permits use of a user-defined send and receive mechanism. However, an implementation based on packeteer is self-evident.


  1. The encryption sub-protocol is a work in progress. ↩︎