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 scheme⁴ based on the The Noise Protocol Framework⁵, which explicitly circumvents complexities present in DTLS⁶.

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

#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.