Summary

  • SQUAD proposes shared multicast delivery for common data while preserving individual QUIC relationships for authentication and control.
  • The 16 November IETF BoF is non-WG-forming: it will collect requirements and evidence, not approve a charter or select a protocol.

The attractive part is easy to draw: one sender, a branching delivery tree, many receivers. The expensive part is everything the picture leaves out. A QUIC receiver still needs its own authenticated relationship. Someone must gather feedback, notice loss, repair it, control congestion and decide what happens when a path or a receiver cannot use the shared stream.

That is the problem behind SQUAD, or Scalable QUIC-Assisted Distribution. The approved request proposes using Source-Specific Multicast (SSM) for common one-to-many data while retaining a conventional QUIC connection to each receiver for authentication and control. QUIC already supplies encrypted, multiplexed transport over UDP; TLS is part of its security design. SSM supplies a network delivery model in which receivers ask for traffic from a specified source. Putting those pieces beside each other does not make the hard coordination question disappear.

The IETF has scheduled SQUAD for 16 November at IETF 127. The label matters: this is a non-working-group-forming Birds of a Feather session. The request says the room will not approve a charter or select a protocol. It is meant to find shared use cases and requirements, expose assumptions that participants dispute, and identify what experiments or follow-up work would be useful. A BoF can open a door; it cannot quietly turn the proposal into an Internet standard.

The request’s open list is a better guide to the stakes than the word “scalable.” Can receiver feedback be combined without hiding a damaged path? How should loss repair work when only some receivers missed a packet? How can congestion control respond when one shared transmission serves paths with different capacity? What keeps one slow or malicious receiver from distorting service for everyone? And when multicast is unavailable, when does a receiver fall back to its own stream?

Those questions shift work across the boundary between sender and network. Unicast makes the sender pay for repeated delivery, but gives it a per-connection view. A shared multicast branch may reduce duplicate traffic on suitable links, while asking the system to coordinate delivery state and exceptions across receivers. The proposal’s use of individual QUIC relationships is an attempt to keep identity and control attached to each receiver while sharing common payload. Whether that split is useful depends on the workload and the networks carrying it.

Existing standards give the discussion parts, not a finished machine. QUIC’s base transport is specified in RFC 9000; TLS use follows RFC 9001; QUIC DATAGRAM is defined by RFC 9221. SSM’s service model is in RFC 4607. Automatic Multicast Tunneling, RFC 7450, describes one way multicast can cross network segments that do not natively provide it. None of those records measures SQUAD’s performance or says that operators will deploy it.

The decisive outcome in November may be less dramatic than a protocol announcement: a tighter problem statement, a set of testable requirements, or a decision that the open questions are too wide for a new working group. That would still be useful. A standards room should make the missing work visible before anyone sells the diagram as a saving.

The captured primary records contain no comparative deployment or performance measurements. Repeatable managed-network tests against unicast would change the assessment of possible savings.

Records: approved SQUAD BoF request; IETF 127 new topics; RFC 9000, RFC 9001, RFC 9221, RFC 4607, RFC 7450.