[Moq] Request Synchronization Use Case
Cullen Fluffy Jennings <fluffy@iii.ca> Fri, 01 May 2026 22:11 UTC
Return-Path: <fluffy@iii.ca>
X-Original-To: moq@mail2.ietf.org
Delivered-To: moq@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D813FE7A2C28 for <moq@mail2.ietf.org>; Fri, 1 May 2026 15:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777673472; bh=MivBc5ach9NqZ2eZnmn/wV7u+qRuPHqAWbVZX5+EE94=; h=From:Date:Subject:To; b=FbRieN4T97XGGd2wjpPpd8TvZvkaBWqFRH+PkGK7Og6LRLufTRtpIxi4/RIjKvfLD y+MFaT1ubCqzIt5pIjZCabBbnvwfKqJIxF6zYKV3wc0BV+hvbgYdQESaMMWksMvWaJ VouxsVObaMgYjBoopux9pQQKOxAd70J/jJfGx55Y=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iii.ca header.b="dMKQMKJp"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Ct5Nua78"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0NOWucKYSN8 for <moq@mail2.ietf.org>; Fri, 1 May 2026 15:11:12 -0700 (PDT)
Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 76A5CE7A2B3E for <moq@ietf.org>; Fri, 1 May 2026 15:10:14 -0700 (PDT)
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 6E0487A00C8; Fri, 1 May 2026 18:10:08 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Fri, 01 May 2026 18:10:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iii.ca; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1777673408; x=1777759808; bh=yA2n+78Hx1 CkrFMvROt+vg1Po6VYlgp4vxGuuLvsRJ4=; b=dMKQMKJpn1yTnKKoF6ut/MSW/J Bw7WooXprkfYHs5BNMbzmcY5JayZcNKkvXXEPAWUXEjC8vJfFa4YzcyfUCe3Lvaa ZaDeN9KbtqwHUh8ZaR4hzRn+57fwh0amNKh7o+FiELGhdgHAsPE47t0xIH2v0i5z KSfrxOwptkFQsDZHnA20lfXwE3/IYpVQuSHFImKJdQPaHXI13qoPHuKX7zoD9zqq mtjv+EKCTCiuXUCmODQWMVnHy4hHeHNRCHY1dyZO1eLAVDBk8ruMb73Q27IkJpmF Fa1ymOd5ph0zacJD3cC8URy2KMY6R3hYwBfJ8NYf7N1lOpPqiID8OIkMBFlw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1777673408; x=1777759808; bh=yA2n+78Hx1CkrFMvROt+vg1Po6VYlgp4vxG uuLvsRJ4=; b=Ct5Nua78mI9pLjH3/P0o90wqEtIEuX3XsaU2cKBjUn1+bSGO1Fe Sg8e6pul/VUPCDSpw+IJRqY3si0ZERcDFKBpS+L8EVVdoYqWf3AW59LBUy0N26Gd hFe8hycFtQ6eWm0nEw05SUaGnkD3sUQtc21hJmJD29ga4GPKmXPn0YJDG/kCLi3K LVoD8WvF2CFakE6OjNiu6zrLJWFCqwkBwzj+nNyzIPoA1VGKK7uoEv/EUlV9M+c2 o6x7c3uMqZYAz29xWraTOS3avgDTjtdP7YKdlwTi2uZYStMF77XgXG6sgfg0m2B7 +3h+S6x44qe1WU0psaOTFLP0GYojsNqP4VA==
X-ME-Sender: <xms:wCT1aTVf6S3Pom3rmKTWjx2GHqi4kg1nYFJwUwdpTzOd5bVJId8m9w> <xme:wCT1aX4UbrQUv1Cfzylzbk8O2Qf3KTrneRAJjW9uXJT560-5unFPImRkqeEigOC7V 7O425Q9KzF6Kf86gBISR5cFD0En9Zxu7hG3b2xGb6ZPPnBqDuQiBwk>
X-ME-Received: <xmr:wCT1aSL3bvBszrbdKH9yDWxyGue-WE54MhNViWamrQw06UzeBk59IimNtZ8VowwlmH5mCZa3mwIGyLIePYqrfD7G7dw9NSAcUyvC-5E>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdeludefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhephfgtgfggfffukffvofesthhqmhdthhdtje enucfhrhhomhepvehulhhlvghnucfhlhhufhhfhiculfgvnhhnihhnghhsuceofhhluhhf fhihsehiihhirdgtrgeqnecuggftrfgrthhtvghrnhepfefhudffgeehueeugeeggfeije egvdevveeltddtudfggedvleeileeujeekleeunecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepfhhluhhffhihsehiihhirdgtrgdpnhgspghrtg hpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhhoqhesihgvthhf rdhorhhgpdhrtghpthhtohepfhhluhhffhihsehiihhirdgtrg
X-ME-Proxy: <xmx:wCT1aQJlMznuaCTW9pC2KI2QumTQoS-Zr_p8aYhsFsEoaN7mI7GMdQ> <xmx:wCT1aQXEwpUZBnl7TQX0RJqbL4TjRRO5doNud5f8yvHz_9SrTNX0-g> <xmx:wCT1aSg9gPLvDwcYHUj1oVJZ0_fFxCunFSYLmwCTv4lqM5scOjUOqw> <xmx:wCT1ab93MnJAhaB1UVJUeovZna1lrHMnvk-3iws_ISQWJIW0Lvd3tA> <xmx:wCT1aYoqqYRnUbLA7KCiwLX5w9XtvbXWy6wJDPq3RPTwsz3lASMPOKRY>
Feedback-ID: icafe48a4:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 1 May 2026 18:10:07 -0400 (EDT)
From: Cullen Fluffy Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
Date: Fri, 01 May 2026 16:10:06 -0600
Message-Id: <E4E2EA18-6FA9-48C6-82DB-6F6D59F9F22E@iii.ca>
To: MOQ Mailing List <moq@ietf.org>
X-Mailer: Apple Mail (2.3864.500.181)
Message-ID-Hash: CCR4L5I3WJVYOOXBVDOZ52N5DZD3G23E
X-Message-ID-Hash: CCR4L5I3WJVYOOXBVDOZ52N5DZD3G23E
X-MailFrom: fluffy@iii.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Moq] Request Synchronization Use Case
List-Id: Media over QUIC <moq.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/YIkbDmf8BZ0Dx41j8QJ7nj0BZMU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/moq>
List-Help: <mailto:moq-request@ietf.org?subject=help>
List-Owner: <mailto:moq-owner@ietf.org>
List-Post: <mailto:moq@ietf.org>
List-Subscribe: <mailto:moq-join@ietf.org>
List-Unsubscribe: <mailto:moq-leave@ietf.org>
I don’t think it is worth trying to repeat all of them here as people can feel free to find them in the previous meetings but let me mention a few 1) Swap tracks. In a video conference, a subscriber is subscribe to track for Alice and Bob’s video and is watching Alice with Bob paused, but wants to pause Alice and unpause the track with Bob. It’s pretty common to want to ensure to pause the current one before unpausing the new track to not have congestion. 2) client side ABR 3) a stream being paused and unpaused in rapid succession and requests reorders on the wire resulting in the opposite of the desired state. I understand the spec never required the relay to strictly enforce order of operations but that was discussed as “quality of implementation” issue and the time that a relay is likely to get them out of sync was always pretty low ignoring upstream request delay which the use cases can avoid. Most high performance implications are likely to local all the traffic on that quic connection to s single set of processing thread anyways further reducing reorder likelihood. I’m a bit concerned with how the chairs are positioning this, at the time of the call it was just a poll about did we need to get this sorted out in -18. I don’t think anyone cared about that as there is already too much in -18. Martin clarified as the poll was about punting this to London at which point the objects on the poll were removed. I’m fine with punting this to London. But after the call I realized what was happening here was the chairs are going to treat this as we no longer have the consensus we had on drafts up to -17 where there was a way to indicate ordering of requests to the proxy. We had no objections to this in last call of -17. We are trying to get to done and reopening base issues about what the requirements are is not helpful. I want to be very clear I would have objected to bidi if it did not have a way synchronize - this is a fundamental part of bidi. I did not think the poll on the call was that we going to remove the consensus we had around -17. I hope we are are going into London with are assumption about synchronization being we do need a way to indicate desired sequencing of requests to the relay and we are sorting out the details of how to do that without introducing dos problems.
- [Moq] Request Synchronization Use Case Cullen Fluffy Jennings
- [Moq] Re: Request Synchronization Use Case Magnus Westerlund
- [Moq] Re: Request Synchronization Use Case Magnus Westerlund
- [Moq] Re: Request Synchronization Use Case Luke Curley
- [Moq] Re: Request Synchronization Use Case Alan Frindell
- [Moq] Re: Request Synchronization Use Case Gwendal Simon
- [Moq] Re: Request Synchronization Use Case Cullen Fluffy Jennings
- [Moq] Re: Request Synchronization Use Case Alan Frindell
- [Moq] Re: Request Synchronization Use Case Gwendal Simon
- [Moq] Re: Request Synchronization Use Case Ali C. Begen
- [Moq] Re: Request Synchronization Use Case Alan Frindell