Return-Path: 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 68BA8DEABF5B for ; Fri, 17 Apr 2026 20:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776482652; bh=A9asups5PK4GUQXlhfYjpgmDdTE7G74HVeYc9WeSqYU=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=D87v0uiVKNpUKS0tG+5ZsT7Bc13SFQSKyou9jEb8ZV+9KwSuEVQOMaQHNctlqCjRQ 6L2S2XE3cZtP1j8IvwAPbbXcAKsb4l2KDLiA+UDgVKeLwNiiCk3ox4W1/SIWMTq5/q 3qImUqAWdCJKn2VYpnnST30F5XybydADdQFYuxcE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XrJYH4tZeEJt for ; Fri, 17 Apr 2026 20:24:11 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 587ECDEABF54 for ; Fri, 17 Apr 2026 20:24:11 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5a0ff30b240so1853489e87.0 for ; Fri, 17 Apr 2026 20:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776482650; cv=none; d=google.com; s=arc-20240605; b=N8TL0ekGg6Wg64RReXtHKp0nVapiBT8tWcNz5y+VScOrwuSJZpghT8fLTnRp9ZJ+Qr C9GaR0GTb+NicTD8qIJwbFydG7oGt6POwzI7Z8daUUXHnEPcGf9NUtVIvc9tpk73ccnh e6JnmbGuplV74ZllTM5u2LvjMw0GIbZBNhqZM4xBqT7hB43Nz/y6MQ22yqMaBem+smnk XgcFK1hT4GAJFdD54d3ERugljh+1Vt4pmPNGrM4BTRAUjJie0ck9t91/89mVIQWp7Vkr pUe8MO/blMZa2t9c55trq9wRFI1ove5DcQ5coXdsCznTbawtKLe2aGDa7JeUW7z3J7dH 88Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=V+bg6aRkruEZhjqdJlIIiXeyWXJdri5vh+lvWALJa9w=; fh=q6KN9/xAr7rNW6GkxoYJe5mAQu5B3aCI2tKaL7hVa9c=; b=gj9Dal2mfJfELYqqazuXNKxsTiTE2llynLWsLtIaZceJYWesXx5q2JQgCxRDkk9I5a bkjnrtgROr8g/eWoK95VNRk5Pkq0mPL9zLi/qBz4ur8Cg4PsS6pePxUvbPVLmPqyWQWF /XTZZzzkNDGEBbdtMTmWbaNZZT047Bi9krDfurwo0YxP1Qf4EtEguaHGsdN+Nlp0fDJL lwEZqfYLZX8qg76CUNFyKXmOErtubl1flzRefI9+HvU6cFnVvnOnY0bWmYu67sMl7crD sVyiTuFbzs5czOl5e0GIuRy/u0vZ8UmbbvjMvQC+/SdUfdqBEh34LLMn81NnFqKNkptH syRw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776482650; x=1777087450; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=V+bg6aRkruEZhjqdJlIIiXeyWXJdri5vh+lvWALJa9w=; b=iG9kK+pPqQVbmbkbd/5SmQgB2NA0CeBosom4ZgEk66V6kb5P2Cj1nlGQwYFFRBdtoU lPRTNTUOVqu7ziJCHmLekKbKQxBm8qBdIIWB8oNL8uejyp3+bs6iSvxLzgEBG8HqKEx8 EEpQfvlYFTgFu0QZTzIoB6R75+DYaHwh75XOpZpwCMCVhlJIBbW/qH/qhWjssF8xdZeT V46X77BUyoelercRDiX5z6cTa2apXlfye32wYTJB5g5ZdExLjUuoGJZEThqnWdoQLuV/ 9Ov3IdYu0kh02KpJPdna4ZQDsi9nbCqssMdu+DJt7nvxuARvXXg5a31v7q2abbjAGdbE 54rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776482650; x=1777087450; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=V+bg6aRkruEZhjqdJlIIiXeyWXJdri5vh+lvWALJa9w=; b=asrYmY5GfWP2DVzy2vxve4lKGmKLdek5uZ/rVrzx4zl8UuL80b9Lvv6tqIQH/HfjSp QDbWVytDus5jhOvh4sDn+Ys2ohzzuKx+4p7/DCDq3KXVtLA0PfN5eaAGsjqTNvGPTcgp stHZejcC6m2sq/CgvAG9cVVbma1xriwIFfPJzFAeJue02BklAQTqQFJgHXWUXH4Orl1a 2qSpPtzapri4dntgzIwra1CfWdX/MAKlhCseNLZQm9oJcPLw7dYWaKcuN4Zf0YwXx4Q0 OTXbi8dG1xLSEgR5/DYDi36OsSbSp0mipW0y9fCxffiC7GYkCIISRJfpuIgBEkIq4O0P PGAQ== X-Forwarded-Encrypted: i=1; AFNElJ+RD1iQaBwkvUmKHdjGrVKgDFzeujg4+8/EL0VHjdNTjYIpOulvybpMMByCuC3s3yRoaM8=@ietf.org X-Gm-Message-State: AOJu0YxOZvIxVmhpVMwY+X80mkcOYUBGClM3d0nzQOSPkiy1MtKw/JtC IHT3TD+nNpuZFGHtIyHyiZf22rkqjpvrXGXMvJtFf94IWo6zGXqyFFm32EJaBD053Cpt7twxCUH 1b3vyt4I/sbvEm5a4iI90vDy7naW/3W4/h+JW74o= X-Gm-Gg: AeBDieu1CclbwkCSKID62NoVVelQrBU1nBisskzEuBT0KlOV0t9A6lmdg+8S6Dfae7i Ns83cRlYJr9x1B4k9yFgFFe/MpTXBWdbx45AVUckF/ab3cbPYRCvIcy+dOd7zlXXzEqlErN28EH U+o7IC15YZWYDTNsl8VU/8bNClauuEGg06M7JGuug2HlaSHwHhK/cGZn7rRJxX9NOQ8W29cWurC vsgK5/qIafJsksWyWw1B0pUnr+8idj/7OiH6vHdNdkpuRdqMizobU8Z/bKjiw9IXYEt6gHTNbD8 rdPjMep9DWsAMPz0OZ2JBEgG7RyaYbZ6Kp7YuPw50626JeK2RUhQ50xJoYLERQ== X-Received: by 2002:a05:6512:3e28:b0:5a3:ff48:f7db with SMTP id 2adb3069b0e04-5a4172e2920mr1436296e87.34.1776482649665; Fri, 17 Apr 2026 20:24:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luke Curley Date: Fri, 17 Apr 2026 20:23:58 -0700 X-Gm-Features: AQROBzAkcYFDB0ncmgbCiG62AvOlh2IUiQOud-pW1GKir4t_1iXgRXCmKA3Zn1Q Message-ID: To: Alan Frindell Content-Type: multipart/alternative; boundary="000000000000487354064fb39978" Message-ID-Hash: 2HME645ZH4Q4NRPMX6YIT3KRBUZ5K6SA X-Message-ID-Hash: 2HME645ZH4Q4NRPMX6YIT3KRBUZ5K6SA X-MailFrom: kixelated@gmail.com 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 CC: Magnus Westerlund , MOQ Mailing List X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BMoq=5D_Re=3A_Consensus_call_on_way_forward_on_REWIND?= List-Id: Media over QUIC Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000487354064fb39978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, I just want to adopt CurrentGroup so we can make *some* progress. IMO the problem with the REWIND proposal... is that we first need to acknowledge the problems with FETCH. I'm pessimistic because we've face planted on this so many times, but here's one more shot: HoLB is a fundamental "feature" of FETCH. For example, if you issue a FETCH for groups 64 - 67, and group 64 is not in the cache, oops we can't start transferring groups 65+ from cache. FETCH introduces HoLB so a dumb VOD client doesn't have to reorder frames, but the cost is under-utilizing the network. A smart VOD client is much better off issuing a separate FETCH request per group, mimicking HLS/DASH. It can avoid the HoLB of FETCH (via priorities) and makes it possible to target a specific buffer size (ex. 30s). Ironically, a smart VOD client doesn't want the aforementioned "vod semantics" provided by FETCH. In my ideal world, we would use "live semantics" for VOD too. Deliver sub-groups on their own stream. But please I need a win: CurrentGroup would be a huge improvement. On Fri, Apr 17, 2026 at 5:30=E2=80=AFPM Alan Frindell wro= te: > > While REWIND is undoubtedly an improvement over LargestGroup, we should > make incremental progress. Does anyone object to a LargestGroup filter? > > I don't object to this conceptually and I even sketched a PR which you ca= n > see here -- I called it > "CurrentGroupFill" -- the Fill part distinguishing the request behavior > from a straight "Filter". > > I feel like it has less to do with the HOLB problems we are discussing an= d > REWIND was intended to solve, and more to do with ironing out the most > common MOQ use case -- joining via a single message and keeping the > response in a more consistent format. It does handle the one case we are > missing in the *current *group (in-cache low-pri subgroups/datagrams), > but doesn't address it for previous groups. > > Thanks > > -Alan > > > On Fri, Apr 17, 2026 at 4:10=E2=80=AFPM Luke Curley = wrote: > >> IMO the root problem with SUBSCRIBE + JOINING FETCH is that subscribers >> want "live semantics". However, the first half, of the first group uses >> "vod semantics". live semantics - Each sub-group is delivered via >> independent >> IMO the root problem with SUBSCRIBE + JOINING FETCH is that subscribers >> want "live semantics". However, the first half, of the first group uses >> "vod semantics". >> >> >> *live semantics*- Each sub-group is delivered via independent streams. >> - Either side may reset a sub-group stream, for any reason, to skip any >> remaining objects. >> - Objects within a sub-group are delivered reliably and in order, until >> reset/fin. >> >> *vod semantics* >> - Objects are delivered over a single stream. >> - Objects are delivered in ID order, regardless of the sub-group. >> - Objects cannot be skipped (authoritative). >> >> >> Yes, it's possible to emulate "live semantics" using "vod semantics". Th= e >> end subscriber *could* issue multiple, sequentially prioritized, JOINING >> FETCH requests for each specific groups/sub-group, merging each aligned >> JOINING FETCH and SUBSCRIBE stream. Just for the first group of course! >> >> It's a gross hack. A complicated set of instructions. Just to command >> the relay to serve the latest group *mostly* via "live semantics". >> >> We should add a LargestGroup filter for SUBSCRIBE instead. It is the >> intended behavior 99% of the time and deserves a flag, not an incantatio= n. >> The first group within a subscription would no longer be special. >> >> While REWIND is undoubtedly an improvement over LargestGroup, we should >> make incremental progress. Does anyone object to a LargestGroup filter? >> >> On Fri, Apr 17, 2026 at 12:31=E2=80=AFPM Alan Frindell > 40meta.com@dmarc.ietf.org> wrote: >> >>> The working group should do nothing with this document at this time. >>> >>> I appreciate the effort Martin and others put in, however, now that >>> FILL_TIMEOUT=3D0 has landed in the Editors=E2=80=99 Copy, the unique ca= pabilities >>> provided by REWIND to avoid HOL blocking are reduced. >>> >>> Specifically we=E2=80=99ve eliminated cases where the subscriber=E2=80= =99s joining FETCH >>> is blocked by cache misses =E2=80=93 set FILL_TIMEOUT=3D0 (JFFT0). So = the following >>> cases are no longer problematic: >>> >>> 1) Cache Hole in low-pri subgroup blocks hi-pri cached object >>> >>> Object ID: 0 1 2 _ 4 >>> >>> Subgroup: 0 1 0 1 0 >>> >>> 3 is low priority and in flight. JFFT0 skips over it and delivers the >>> current cache state. Object 3 can come later via SUBSCRIBE, assuming w= e >>> allow a range filter (for new objects) to start at the current group. >>> >>> 2) Datagram or stream-per-object track with a cache hole: >>> >>> 0 1 2 3 _ 5 >>> >>> Cached objects all get delivered with no HOLB. >>> >>> 3) Old group has been evicted: >>> >>> Groups in Cache: _ 98 99 100 >>> >>> Current Group: 100 >>> >>> JFFT0, Relative -3 >>> >>> The FETCH response begins immediately at 98, with previous marked >>> =E2=80=9CUNKNOWN=E2=80=9D. >>> >>> >>> There=E2=80=99s one remaining case where REWIND provides a HOLB advanta= ge: when >>> lower priority data *IS* in the cache, but you don=E2=80=99t want to HO= L block >>> on it. >>> >>> This can be addressed by adding a subgroup and/or priority filter to >>> FETCH, which is a small subset of PR #1518. >>> >>> In the happy-cache case, REWIND also serves as a =E2=80=9Csingle wire m= essage=E2=80=9D, >>> and saves the subscriber from stitching together the current group from >>> multiple streams, but the working group identified HOLB as the problem = to >>> solve. I got the feeling that the non-deterministic nature of REWIND l= eft >>> others feeling unsatisfied. But if you want determinism, you are >>> acknowledging that some head-of-line blocking on cache fill is a >>> feature and not a bug. >>> >>> The lively discussion in Boulder and at the recent interim indicates >>> that despite all our efforts, there=E2=80=99s some friction in MOQT aro= und >>> SUBSCRIBE, FETCH and joining an ongoing Track. The lack of clear conse= nsus >>> around a different direction forward indicates we=E2=80=99re probably c= lose to the >>> best we can achieve in the V1 timeframe. We should stabilize around th= e >>> core we have, and let innovation take place in extensions. If there=E2= =80=99s a >>> better solution, it will emerge and it can be codified in a V2. Thanks >>> >>> >>> -Alan >>> >>> >>> On Thu, Apr 16, 2026 at 6:58=E2=80=AFAM Magnus Westerlund >> 40ericsson.com@dmarc.ietf.org> wrote: >>> >>>> WG, We spent Monday's interim talking about https: //github. >>>> com/martinduke/draft-duke-moq-subscribe-rewind/tree/main. There was a = lot >>>> of interest to do something in this space but little agreement on the = key >>>> properties of a solution. This document >>>> WG, >>>> >>>> We spent Monday's interim talking about >>>> https://github.com/martinduke/draft-duke-moq-subscribe-rewind/tree/mai= n. >>>> There was a lot of interest to do something in this space but little >>>> agreement on the key properties of a solution. >>>> >>>> This document is meant to resolve several issues and PRs related to >>>> Joining Fetch : >>>> #861, #1039, #1358, #1362, #1386 >>>> https://github.com/moq-wg/moq-transport/issues >>>> >>>> >>>> As well as the conclusion of the Joining Fetch discussion in Boulder, >>>> which is that people did not like head-of-line blocking in Joining Fet= ch. >>>> https://datatracker.ietf.org/doc/minutes-interim-2026-moq-06-202602102= 030/#comparing-proposals >>>> >>>> >>>> >>>> This is a consensus call for the disposition of this document. Please >>>> state your preference. >>>> 1) The working group does nothing with this document, at least until >>>> MOQT is published >>>> 2) The working group adopts this draft as the basis for an MOQT >>>> extension >>>> 3) The working group uses the draft as basis for a PR to be merged >>>> into MOQT when the Editors feel the PR is ready. >>>> >>>> Please provide your input no later than Friday the first of May >>>> (260501). >>>> >>>> Other proposals in this space are welcome, and subject to the same >>>> consensus requirements. >>>> >>>> Magnus Westerlund >>>> MoQ Chair >>>> >>>> -- >>>> Moq mailing list -- moq@ietf.org >>>> To unsubscribe send an email to moq-leave@ietf.org >>>> >>> -- >>> Moq mailing list -- moq@ietf.org >>> To unsubscribe send an email to moq-leave@ietf.org >>> >> --000000000000487354064fb39978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I just want to adopt CurrentGroup so we can mak= e some progress.


IMO the pro= blem with the REWIND proposal... is that we first need to acknowledge the p= roblems with FETCH. I'm pessimistic=C2=A0because we've face planted= on this so many times, but here's one more shot:

<= div>HoLB is a fundamental "feature" of FETCH. For example, if you= issue a FETCH for groups 64 - 67, and group 64 is not in the cache, oops w= e can't start transferring=C2=A0groups 65+ from cache. FETCH introduces= HoLB=C2=A0so a dumb VOD client doesn't have to reorder frames, but the= cost is under-utilizing the network.

A smart VOD = client is much better off issuing a separate FETCH request per group, mimic= king HLS/DASH. It can avoid the HoLB of FETCH (via priorities) and makes it= possible to target a specific buffer size (ex. 30s). Ironically, a smart V= OD client doesn't want the aforementioned "vod semantics" pro= vided by FETCH.

In my ideal world, we would use &q= uot;live semantics" for VOD too. Deliver sub-groups on their own strea= m.

But please I need a win: CurrentGroup would be = a huge improvement.


On Fri, Apr 17, 202= 6 at 5:30=E2=80=AFPM Alan Frindell <a= frind@meta.com> wrote:
> While REWIND is undoubtedly an improvement over Lar= gestGroup, we should make incremental progress. Does anyone object to a Lar= gestGroup filter?

I don't object to this conceptually and I even sketched a PR= which you can see here -- I called it "CurrentGroupFill" = -- the Fill part distinguishing the request behavior from=C2=A0a straight &= quot;Filter".

I feel like it has less to do with the HOLB problems w= e are discussing and REWIND was intended to solve, and more to do with iron= ing out the most common MOQ use case -- joining via a single message and ke= eping the response in a more consistent format.=C2=A0 It does handle the on= e case we are missing in the current group (in-cache low-pri subgrou= ps/datagrams), but doesn't address it for previous groups.

Thanks

-= Alan


On Fri, Apr 17, 2026 at 4:10=E2=80=AFPM Luke Curley <= ;kixelated@gmail.c= om> wrote:
IMO the root problem with SUBSCRIBE + JOINING FETCH is that subscribers wan= t "live semantics". However, the first half, of the first group u= ses "vod semantics". live semantics - Each sub-group is delivered= via independent
IMO the root problem with SUBSCRIBE + JOINING FETCH i= s that subscribers want "live semantics". However, the first half= , of the first group uses "vod semantics".

live semantics
- Each sub-group is deliver= ed via independent streams.
- Either side may reset= a sub-group stream, for any reason, to skip any remaining objects.
- Objects within a sub-group are delivered reliably and in= order, until reset/fin.

vod semantics
- Objects are delivered over a single stream.
- = Objects are delivered in ID order, regardless of the sub-group.
- Objects cannot be skipped (authoritative).


Yes, i= t's possible to emulate "live semantics" using "vod sema= ntics". The end subscriber could issue multiple, sequentially p= rioritized, JOINING FETCH=C2=A0requests for each specific groups/sub-group,= merging each aligned JOINING FETCH and SUBSCRIBE stream. Just for the firs= t group of course!

It's a gross hack. A complicated = set of instructions. Just to command the=C2=A0relay to serve the latest gro= up mostly via "live semantics".=C2=A0

=
We should add a LargestGroup filter for SUBSCRIBE instead. It is the i= ntended behavior 99% of the time and deserves a flag, not an incantation. T= he first group within a subscription would no longer be special.
=
While REWIND is undoubtedly an improvement over LargestGroup= , we should make incremental progress. Does anyone object to a LargestGroup= filter?

On Fri, Apr 17, 2026 at 12:31=E2=80=AFPM Alan Frindell <= afrind=3D40m= eta.com@dmarc.ietf.org> wrote:

The working group should do nothing with this document at this time.


I appreciate the effort Martin and others = put in, however, now that FILL_TIMEOUT=3D0 has landed in the Editors=E2=80= =99 Copy, the unique capabilities provided by REWIND to avoid HOL blocking = are reduced.


Specifically we=E2=80=99ve = eliminated cases where the subscriber=E2=80=99s joining FETCH is blocked by= cache misses =E2=80=93 set FILL_TIMEOUT=3D0 (JFFT0).=C2=A0 So the followin= g cases are no longer problematic:


1) Cache Hole in low-pri subgroup blocks hi-pri cached object


Object ID:=C2=A0 =C2=A0 0 =C2=A0 1 =C2=A0 = 2 =C2=A0 _ =C2=A0 4

Subgroup: =C2=A0 0 =C2= =A0 1 =C2=A0 0 =C2=A0 1 =C2=A0 0


3 is lo= w priority and in flight.=C2=A0 JFFT0 skips over it and delivers the curren= t cache state.=C2=A0 Object 3 can come later via SUBSCRIBE, assuming we all= ow a range filter (for new objects) to start at the current group.

2) Datagram or stream-per-object= track with a cache hole:


0 =C2=A0 1 =C2= =A0 2 =C2=A0 3 =C2=A0 _=C2=A0 =C2=A0 5


Cached objects all get delivered with no HOLB.


3) Old group has been evicted:


Groups in Cache: =C2=A0 _ =C2=A0 98 =C2=A0 99 =C2=A0 100

Current Group: 100


JFFT0, Relative -3


The FETCH r= esponse begins immediately at 98, with previous marked =E2=80=9CUNKNOWN=E2= =80=9D.



= There=E2=80=99s one remaining case where REWIND provides a HOLB advantage: = when lower priority data IS in the cache, but you don=E2=80=99t want= to HOL block on it.


This can be address= ed by adding a subgroup and/or priority filter to FETCH, which is a small s= ubset of PR #1518.


In the happy-cache ca= se, REWIND also serves as a =E2=80=9Csingle wire message=E2=80=9D, and save= s the subscriber from stitching together the current group from multiple st= reams, but the working group identified HOLB as the problem to solve.=C2=A0= I got the feeling that the non-deterministic nature of REWIND left others = feeling unsatisfied.=C2=A0 But if you want determinism, you are acknowledg= ing that some head-of-line blocking on cache fill is a feature and not a bug= .


The lively discussion in Boulder and a= t the recent interim indicates that despite all our efforts, there=E2=80=99= s some friction in MOQT around SUBSCRIBE, FETCH and joining an ongoing Trac= k.=C2=A0 The lack of clear consensus around a different direction forward i= ndicates we=E2=80=99re probably close to the best we can achieve in the V1 = timeframe.=C2=A0 We should stabilize around the core we have, and let innov= ation take place in extensions.=C2=A0 If there=E2=80=99s a better solution,= it will emerge and it can be codified in a V2. Thanks


-Alan<= /p>


On Thu, Apr 16, 2026 at 6:58=E2=80=AFAM Magnus Westerlu= nd <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote:
WG, We spent Monday's interim talking about https:=E2=80=8A//github.=E2= =80=8Acom/martinduke/draft-duke-moq-subscribe-rewind/tree/main. There was a= lot of interest to do something in this space but little agreement on the = key properties of a solution. This document
WG,

W= e spent Monday's interim talking about
https://github.com/martinduke/draft-duke-moq-subscribe-rewind/= tree/main. There was a lot of interest to do something in this space but little agree= ment on the key properties of a solution.

This document is meant to resolve seve= ral issues and PRs related to Joining Fetch :
#861, #1039, #1358, #1362, #1386


As well as the conclusion of the Joini= ng Fetch discussion in Boulder, which is that people did not like head-of-l= ine blocking in Joining Fetch. https://datat= racker.ietf.org/doc/minutes-interim-2026-moq-06-202602102030/#comparing-pro= posals


This is a consensus call for the dispo= sition of this document. Please state your preference.
1) The working group does nothing with= this document, at least until MOQT is published
2) The working group adopts this draft= as the basis for an MOQT extension
3) The working group uses the draft as basis for a PR to be=C2=A0merged into MOQT when the Editors feel the PR is ready.

Please provide your input no later than Friday the first of May (260501).= =C2=A0

Other proposals in this space are welc= ome, and subject to the same consensus requirements.

Magnu= s Westerlund
MoQ C= hair

--
Moq mailing list -- moq@i= etf.org
To unsubscribe send an email to moq-leave@ietf.org
--
Moq mailing list -- moq@i= etf.org
To unsubscribe send an email to moq-leave@ietf.org
--000000000000487354064fb39978--