Title :Hummingbird: Fast, Flexible, and Fair Inter-Domain Bandwidth Reservations
Authors :Karl Wüst (Mysten Labs), Giacomo Giuliari (Mysten Labs), Markus Legner (Mysten Labs), Jean-Pierre Smith (Mysten Labs), Marc Wyss (ETH Zurich), Jules Bachmann (ETH Zurich), Juan A. Garcia-Pardo (ETH Zurich), Adrian Perrig (Mysten Labs)
Introduction
This paper addresses the long-standing problem of providing Quality-of-Service (QoS) guarantees across the Internet. Today’s Internet mostly operates on a best-effort basis, which is insufficient for latency-sensitive and bandwidth-critical applications such as video calls, cloud gaming, financial trading, or B2B communications. Existing QoS and reservation systems (e.g., IntServ, DiffServ, Colibri, Helia) either lack flexibility, introduce excessive control-plane complexity, or fail to incentivize providers. This makes global-scale QoS guarantees impractical today.
Key idea and contribution :
The authors propose Hummingbird, a novel inter-domain bandwidth reservation system with three key contributions:
Tradable reservations: Reservations are represented as blockchain-based assets, enabling bandwidth markets where Autonomous Systems (ASes) can sell and trade capacity, ensuring economic fairness and strong incentives.
Smart contract control plane: A decentralized control plane built on high-performance blockchains (Sui) supports atomic end-to-end path reservations, avoiding complex multi-party coordination.
Lightweight data plane: Integrated with SCION, Hummingbird enforces reservations on a per-hop basis with efficient cryptographic tags, providing flexible, composable, and secure reservations.
Evaluation
The authors built a prototype and evaluated both control and data planes:
Control plane reservations complete in under 3 seconds at a cost of about $0.038 per hop, much cheaper than centralized payment systems or Ethereum.
The data plane achieves 160 Gbps forwarding on commodity hardware with minimal CPU, and reservation enforcement only adds ~185 ns latency compared to best-effort forwarding.
This result is significant because it demonstrates that secure, incentivized, and deployable inter-domain QoS is feasible without prohibitive costs or performance penalties.
Q&As
Q1: Does Hummingbird require specialized routers to implement reservations?
A1: Yes, but only partially. Hummingbird builds on SCION. To deploy SCION, only border routers need replacement; intra-domain routers remain unchanged. Once SCION is deployed, Hummingbird can be added at edge routers as an extension. If SCION is not deployed, you must deploy SCION first. Since SCION provides path transparency, the source already knows which ASes a packet will traverse and can place reservations directly.
Q2: Since reservations are atomic transactions, is the system more about control than coordination? And does the smart contract expose commercially sensitive information, such as interface capacity?
A2: Atomicity ensures either all reservations succeed or none, simplifying coordination. But yes, in the prototype ASes must list interface capacities (e.g., “10 Gbps available”), which is visible on the blockchain ledger. This may leak information about popular routes. Future work may add privacy-preserving mechanisms so only reservation success/failure is revealed, not exact capacities.
Q3: SCION supports many disjoint paths for fast failover. But in Hummingbird, bandwidth seems bound to a single path. How can we keep robustness without buying multiple reservations and paying many times?
A3: There are several approaches: (1) Buy multiple reservations and use failover. (2) Use SCION’s multipath routing to split traffic (e.g., 60% on one path, 40% on another). If one fails, only the missing fraction needs to be bought. (3) In the future, support reservations over sets of paths with joint enforcement rather than per-path.
Q4: How does pricing of bandwidth assets work in practice? Fixed or variable? And what happens if an AS misbehaves after a reservation is established?
A4: In the prototype, pricing works like a spot market: ASes post fixed prices, and you pay proportionally (e.g., 10% bandwidth = 10% price). More advanced approaches could use auctions (e.g., VCG) for incentive-compatible pricing. Regarding misbehavior: if an AS is malicious, no system can guarantee delivery, since it can drop or reroute traffic. However, SCION’s multipath routing allows sources to avoid misbehaving ASes over time and shift traffic toward reliable ones.
Personal thoughts
I appreciate the paper’s combination of networking and economics. The introduction of tradable bandwidth assets is a clever way to solve the deployment incentive problem that has plagued previous QoS systems. I also like that Hummingbird prioritizes practical deployability—leveraging SCION and avoiding unnecessary complexity like gateways or duplicate suppression.
However, I am concerned about adoption challenges: Will ISPs and ASes really join bandwidth markets? How can legacy applications and systems make use of Hummingbird without modification? There is also a dependency on blockchain governance, which might create new complexities.
Future research could explore dynamic pricing under congestion, integration with multipath transport protocols, or extending incentive models to include CDNs and cloud providers.