BitTorrent BEP 6 Fast Allowed Extension Explained

The BitTorrent Enhancement Proposal 6 (BEP 6), known as the Fast Extension, introduces several optimizations to the standard BitTorrent protocol to improve network efficiency and peer bootstrapping. Central to this specification is the “Allowed Fast” mechanism, a feature designed to bypass traditional bandwidth choking limitations. This article provides a clear overview of BEP 6, explains how the Allowed Fast set is generated, and details how it permits peers to download specific pieces of data even while being actively choked.

The Choking Mechanism in Standard BitTorrent

In the baseline BitTorrent protocol, peer interaction relies heavily on “choking.” When a client chokes a peer, it stops sending data blocks to that peer, usually as part of a tit-for-tat strategy to incentivize uploading. Under classic rules, if a peer is choked, any piece requests it sends are ignored.

This creates a bootstrapping problem: a newly joined peer with zero completed pieces has nothing to upload, making it difficult to earn unchoked status from other peers. Furthermore, peers close to finishing a download can experience long delays if the few remaining pieces they need are held by peers who currently have them choked.

What is BEP 6 (Fast Extension)?

BEP 6 introduces a set of protocol extensions—including Suggest Piece, Reject Request, Have All, Have None, and Allowed Fast—to eliminate unnecessary latency and reduce overhead.

The most impactful of these additions is the Allowed Fast message. It defines a selective exemption to the choking rule, allowing peers to request and receive a small, predefined set of pieces regardless of whether their connection state is choked or unchoked.

How the “Allowed Fast” Set Works

When two peers connect and both support BEP 6, the serving peer generates an “Allowed Fast” set for the receiving peer. This process operates under specific rules:

1. Deterministic Calculation: The pieces included in the Allowed Fast set are calculated using a standardized hashing algorithm defined in BEP 6. This algorithm takes the serving peer’s IP address, the client’s IP address, and the torrent’s infohash as inputs. Because the formula is deterministic, both peers compute the exact same set of piece indices independently.
2. Transmission of Allowed Fast Messages: The serving peer sends one or more Allowed Fast messages (message ID 0x11) containing the piece indices the remote peer is permitted to download.
3. Requesting While Choked: When the remote peer is choked, it normally cannot request data. However, for pieces listed in its Allowed Fast set, it can still send standard Request messages.
4. Fulfilling the Request: Instead of dropping or rejecting the request, the choked peer recognizes that the requested piece is within the Allowed Fast list and transmits the requested Piece data.

Why Allowed Fast Improves Swarm Performance

The Allowed Fast extension solves critical edge cases in BitTorrent swarms:

• Faster Peer Bootstrapping: New peers can immediately fetch a few pieces without waiting for an unchoke cycle. Once they possess these pieces, they can begin uploading them to other peers, integrating into the swarm’s tit-for-tat economy much faster.
• Reduced Overhead: In standard BitTorrent, choked peers often spam request messages during unchoke transitions. BEP 6 explicitly defines clear boundaries, allowing peers to fetch what is available without redundant requests.
• Elimination of “Endgame” Stalls: Peers that only need one or two pieces to complete a torrent do not need to wait indefinitely for an unchoke slot to open on a specific peer that holds those final blocks.