Function pipe_control 

async fn pipe_control(
    recv: PeekedRecv,
    send: SendStream,
    side: ProxySide,
    key: StreamKey,
    requests: Receiver<StreamCommand>,
    ctx: &ForwardCtx,
) -> Result<(), ProxyError>

Pipe one direction of a stream carrying MoQT control-message framing.

Three kinds of stream reach here, and they are the same shape on the wire: the two directions of a bidirectional control stream on drafts 07-16, one unidirectional control stream on drafts 17-19, and either direction of a request stream on drafts 17-19 — draft-17 Section 9 says “Every message on a control or request stream is formatted as follows”, one framing for both.

What separates them is not this function but what reaches its requests channel: a control direction’s channel is one of the session’s two control legs, so it carries injections; a request stream’s is the per-stream channel the registry hands a reset_stream to, and nothing routes an injection there.

Bytes are forwarded to the peer immediately upon receipt — the parser runs on a cloned copy purely to emit observer events. A stuck or erroring parser can never block forwarding. This matches the pass-through semantics of the data-stream and datagram paths.

If ctx.draft_is_fixed is false (moq-00 cohort, drafts 07–14), the parser start is deferred until enough bytes arrive to peek the first SETUP message and pick a concrete draft. Bytes observed during that detection window are still forwarded immediately.