MIME-Version: 1.0
References: 
 <CAKcm_gPVnSLx=3eTzqU6mkCHTTMZx3Px_RyKB+RgqdZ5oRyMEg@mail.gmail.com>
In-Reply-To: 
 <CAKcm_gPVnSLx=3eTzqU6mkCHTTMZx3Px_RyKB+RgqdZ5oRyMEg@mail.gmail.com>
From: Aman Sharma <amsharma@meta.com>
Date: Wed, 21 Oct 2026 19:36:34 -0700
Message-ID: 
 <CAKXiRhMg5PG1Ac-LCfCA+LadiRbUtKEMsrssKQudA_KkeN1WLg@mail.gmail.com>
To: Ian Swett <ianswett@google.com>
Content-Type: multipart/alternative; boundary="0000000000000ecd9e065e64bc52"
Message-ID-Hash: PNJ77SSSYUQ3YKKB6MJL3EBFAYOJ22M4
CC: MOQ Mailing List <moq@ietf.org>
Precedence: list
Subject: [Moq] Re: Simplifying the Object ID Model and caching
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/moq/dNeSvCCGo_MMK4aAu62jgbR7r-0>

--0000000000000ecd9e065e64bc52
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree that this would be a simplification, and would allow us to remove
the Prior Object ID Gap property. Any implementation relying on
non-contiguous object IDs could trivially define its own parameter to
convey the information previously conveyed through object IDs.


On Wed, Oct 21, 2026 at 7:00=E2=80=AFPM Ian Swett <ianswett=3D
40google.com@dmarc.ietf.org> wrote:

> I believe all members of this WG can agree that the MoQ Object Model is
> too complex. In the past, we've been unable to simplify it, but I believe
> there is a simplification that improves caching and is acceptable. That's
> sequentially
>=20
> I believe all members of this WG can agree that the MoQ Object Model is
> too complex. In the past, we've been unable to simplify it, but I believe
> there is a simplification that improves caching and is acceptable.
>
> That's sequentially increasing Object IDs beginning at 0 (ie: 0, 1, 2, 3,
> etc).  This makes it trivial to know when all the Objects in a Group have
> been received once the End of Group is received, and it avoids unnecessary
> Fetches upstream when a Track is initially Subscribe-delivered and then
> cached.
>
> I realize there is an attraction to ascribing a meaning to the Object ID
> (e.g., using it for the timestamp), but the byte savings are minimal at
> best and this makes MoQ much more brittle. Don't think I haven't tried.
>
> Are there people for whom this would break their usecase and can
> they explain why?
>
> Ian
> _______________________________________________
> Moq mailing list -- moq@ietf.org
> To unsubscribe send an email to moq-leave@ietf.org
>

--0000000000000ecd9e065e64bc52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span id=3D"gmail-docs-internal-guid-39c3ba6e-7fff-4076-9b=
e8-eb7ea5aa83ad"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-serif=
;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical=
-align:baseline;white-space:pre-wrap">I agree that this would be a simplifi=
cation, and would allow us to remove the Prior Object ID Gap property. Any =
implementation relying on non-contiguous object IDs could trivially define =
its own parameter to convey the information previously conveyed through obj=
ect IDs.</span></p></span><br class=3D"gmail-Apple-interchange-newline"></d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Wed, Oct 21, 2026 at 7:00=E2=80=AFPM Ian Swett &lt;ia=
nswett=3D<a href=3D"mailto:40google.com@dmarc.ietf.org">40google.com@dmarc.=
ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div class=3D"msg3146987331241570895">


<div style=3D"font-size:1px;color:rgb(255,255,255);line-height:1px;max-heig=
ht:0px;opacity:0;overflow:hidden;display:none">
I believe=C2=A0all members of this WG can agree that the MoQ Object Model i=
s too complex. In the past, we&#39;ve been unable to simplify it, but I bel=
ieve there is a simplification that improves caching and is acceptable. Tha=
t&#39;s sequentially</div>


<div style=3D"font-size:1px;color:rgb(255,255,255);line-height:1px;max-heig=
ht:0px;opacity:0;overflow:hidden;display:none"></div>


<div dir=3D"ltr">I believe=C2=A0all members of this WG can agree that the M=
oQ Object Model is too complex. In the past, we&#39;ve been unable to simpl=
ify it, but I believe there is a simplification that improves caching and i=
s acceptable.<div><br></div><div>That&#39;s sequentially increasing Object =
IDs beginning at 0 (ie: 0, 1, 2, 3, etc).=C2=A0 This makes it trivial to kn=
ow when all the Objects in a Group have been received once the End of Group=
 is received, and it avoids unnecessary Fetches upstream when a Track is in=
itially Subscribe-delivered and then cached.</div><div><br></div><div>I rea=
lize there is an attraction to ascribing a meaning to the Object ID (e.g., =
using it for the timestamp), but the byte savings are minimal at best and t=
his makes MoQ much more brittle. Don&#39;t think I haven&#39;t tried.</div>=
<div><br></div><div>Are there people for whom this would break their usecas=
e and can they=C2=A0explain why?</div><div><br></div><div>Ian</div></div>
_______________________________________________<br>
Moq mailing list -- <a href=3D"mailto:moq@ietf.org" target=3D"_blank">moq@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:moq-leave@ietf.org" targe=
t=3D"_blank">moq-leave@ietf.org</a><br>
</div></blockquote></div>

--0000000000000ecd9e065e64bc52--