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 A98BCE8F00A5 for ; Mon, 4 May 2026 13:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777924872; bh=BRc2PLfDZ8Y3MC0Jgw8pq9YpK28zn00JNDq+YByJGuM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=GmwthvVhiydl5VclFNqdduGIf5cHwGCsjT4MVT4a+nC8W5mInRAV6yFN+sLYN97Gq ZZashRG1S5YOOXYDkoesewwW4G9neeqhQR0l0FvSABRkPAp9msBPEMXHA4RIrySxVx vuv5ff5MnuxGb2Ee+fdvPS/KfZwDI8cQ6ktU+B10= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 3ESQN9GB5R7D for ; Mon, 4 May 2026 13:01:11 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 6CD71E8F0076 for ; Mon, 4 May 2026 13:01:11 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a3af1b7549so5981265e87.1 for ; Mon, 04 May 2026 13:01:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777924870; cv=none; d=google.com; s=arc-20240605; b=KPfXbwGagFAiCAD0RThqSqZ+YWYleSixwAN69zYjHZzm0M60ilyPeQq4clZKYq0Ee6 qm5Jd7EuIIG2SaKYMahZBopnvYy9AVf1smZWm1MYnIK9JlAwO3zO87d2i3H/nDoG3Ygu c2W3d/kHOusOpK0fnJ7CviF1UHN26eP+9Uw770svJhnMHpIuT5AdF+DcZMf4VDVSN1oI 8/OqzXTlAc5tl2USB8U2uFyo31tCkzpVpw5UaSRkKn6pSsUVoAmpY7BMalufxi0n8M3j PtShq2d55fGPgoqzO0C4Z6CmMVU3k0/mitjoWv0hb7Wjso/ywgREko3Gwxoi3+Uuig/7 UPYg== 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=dAg6RiOh23fyauQp7tT3XhfwatIjEB3ZM9KQ4ZOWUhE=; fh=88LTCGbFW+jhSFDRjT62uX+GaHsLEXU/oj1uz0UR2gw=; b=iuAvyLoxG5q9L/NCQ092wol93NNVJFrq9KJ7q7feuyBC7EtD3JpXD+E1I8grCCO3fJ uKpRP8m2JN33gx6/Mk7SwfrLLVmFIiJW2CUitpvJAk1jn1mkIGhDijeLHqYkmwlZa+Pd Jp+bKoGyJ8xTNT0ksh2rv0ZTfXRb4L+spHK2IsqrvC8Y4jvuDmMacDCVuNNv6qpUj3ic 6vSDaP9yqMfyBOMAf+xXdxnXTavrdvqVur2cCp3SVD9cLBOvkHMjPCrt6zEolebrIjDm wS3cCDl5xgzZH8q0sG/0iZOQrtNRrgdOsl5QrrtFtzpJZBTU0AjejZOv7IwyiGYhq9zB Nwiw==; 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=1777924870; x=1778529670; 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=dAg6RiOh23fyauQp7tT3XhfwatIjEB3ZM9KQ4ZOWUhE=; b=AaJfJgIruoP+OOdVp8e/KXEAqCZU87vFDCg13J+xhWZ1r1+5jBCOPU/51c/71OevXN LWHXaaXmaoW87PJTxrwRTCxCJ+ZX75Qi2fiy48RdQmplp/Mi3Qw777ircr+vvJpvfxXn ltj2EnVi2c0YNHds4cG+19a1X4EQL/hHnoGTk69Qh/L+tNmCmfpliq91X6XpHRPpVo5o +WbWYBQ761+Rq+FQf2eSKqiHBtga7S5eVH0xNwk/j9XGkKH5aFb6SyYzbdRdrrRrV0ut zAmJ7VLZg4wBYtmNQitX8xNJlgyLJury08m9rwkqf1e4LHR6uY5cHpHNDjhNb5m1StFu U8Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777924870; x=1778529670; 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=dAg6RiOh23fyauQp7tT3XhfwatIjEB3ZM9KQ4ZOWUhE=; b=OOTGgt2o6JTOpMhxGxB8Xx4O348YNNyuVBxs/OxBMQREjHkti/PHnFZcLr0Zt7rF2i +W4zqwrdeGYOEbcxsa6NkZ9zcan3ZZLNQ4PgGeCud9u+uOtYFI1EMjYrEU+cwjiA3LPL taxH+Td+zNfBw7Ch2AcbzpW5CNvJbqS9LdpHly6xbi/xgBUvAO7x8rnIABFKOhWGS+QX pqJOGouaGk9CWdvWb4kdZqdK+1tMK01vwBEkMsQI2RwX2ciFuAQMJln0qMJguMxD4OFc On7w8NfRNLWD8THEuHs5uvPgtaRHM/jXnFRatuQgvcqApOgbnb2C05ElDEVsG5hzubg/ y1WA== X-Forwarded-Encrypted: i=1; AFNElJ+NQeWHi7B48s5kHQxvtoBfeeJ1SgIxm6XYbCGLHvxlbY0Ic5x7G422InCFuCB5FqcRxsM=@ietf.org X-Gm-Message-State: AOJu0Yxq2Dfhn6cW764PAWlujIVtMFSt/rxlhQrqHq3tmTvVp6LbjMW0 lkv3ryAveu+caGs1Er/ZhsPxViZJ5GXAEguSRrK3F2iWqnxOjhweGKKruNWV2J7LSbk+gp1KFku 1hyCHYEBkcr06vs09//Cupq3fQMfyILo= X-Gm-Gg: AeBDiesCErCASPWAtkckwtv9jzctEeSHn3d0wyy+/rrYAF+thDBxM0Z9DfWdu+L3IBb EnVAy6b6UfTzmPelOLJQ6VtzlJCycknmGvXBpsvdUOBfJ7Grf1RA2P57JmdfGpk5giyJ+8nllrV kev3PAAwSdUQ79+co5aG6vuEP17xYksj5rF7x4AI5OYNx9PjiUj/zYJ3Q1EcwKJZehJ88YXQuMO m78l/YAuh/H/dSDDtuCY3DX38mmx5OXrVWO4YQ7iM6Abvn9+/EOq8p9voBdH1HzDXPH9bJTX+ME gjZG1sX3YAnxmysPEWQGtx2I61/7OVyCaliBaJU25GN8bU6k4jvvdbKz8qzHaSKsVBP7zWO+Q5O urmoLZJhL X-Received: by 2002:a05:6512:3f0b:b0:5a8:6d09:483c with SMTP id 2adb3069b0e04-5a86d0948c6mr2543182e87.22.1777924869829; Mon, 04 May 2026 13:01:09 -0700 (PDT) MIME-Version: 1.0 References: <2C11C671-0812-4152-9804-03C80372B164@iii.ca> In-Reply-To: From: Luke Curley Date: Mon, 4 May 2026 13:00:59 -0700 X-Gm-Features: AVHnY4Lc6rp0An2Ur7yc4vNYAJ3ldS2HqzocyWdtHcEL-K29h2BUwA8Hgy6-QPg Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary="0000000000004db775065103646f" Message-ID-Hash: ZFYMOT4ZKX74XMYY5JL2MTDIWGISLHF7 X-Message-ID-Hash: ZFYMOT4ZKX74XMYY5JL2MTDIWGISLHF7 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: "Mo Zanaty (mzanaty)" , Ian Swett , Cullen Fluffy Jennings , Magnus Westerlund , MOQ Mailing List X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BMoq=5D_Re=3A_Knowing_the_start_of_a_Subgroup?= List-Id: Media over QUIC Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000004db775065103646f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What are the use-cases for a sub-group per object/datagram? I think for media, it would be sending each b-frame as a separate sub-group. What would be the ideal prioritization there? On Mon, May 4, 2026, 10:41=E2=80=AFAM Suhas Nandakumar wrote: > I think the question comes down to is there a use-case where we need more > than 256 subgroups and needs to be considered for prioritization. I can't > think of one, but love to hear from others. > > On Mon, May 4, 2026 at 10:36=E2=80=AFAM Mo Zanaty (mzanaty) 40cisco.com@dmarc.ietf.org> wrote: > >> If an app has no need for Subgroup ID semantic meaning, it can send an >> unlimited number of objects as separate streams using the same ID (e.g. = 0) >> and reset-at. This seems really ugly, so I=E2=80=99d be willing to have = a special >> header type for single-object stream if that is a strong use case. I agr= ee >> with the comments in I#1405 that this may be closer to datagram than str= eam >> conceptually, which may motivate a specific header type that merges the >> desired properties of datagram and stream. >> >> If the stream-per-object case can be achieved without many subgroup IDs, >> then maybe a single byte is acceptable. >> >> Thanks, >> Mo >> >> >> ------------------------------ >> *From:* Ian Swett >> *Sent:* Monday, May 4, 2026 12:56:05 PM >> *To:* Mo Zanaty (mzanaty) >> *Cc:* Cullen Fluffy Jennings ; Magnus Westerlund < >> magnus.westerlund@ericsson.com>; MOQ Mailing List >> *Subject:* Re: [Moq] Re: Knowing the start of a Subgroup >> >> I believe the concern with making Subgroup ID a single byte is if you >> wanted to do Object-per-Subgroup and couldn't or didn't want to use >> datagrams, you'd be limited to 256 Objects per Group. >> >> Otherwise, making Subgroup ID a byte a very appealing change. Thinking >> along those lines is what caused me to file #1405 >> (Single Object >> Subgroups don't need a Subgroup ID) >> >> Ian >> >> >> On Mon, May 4, 2026 at 12:24=E2=80=AFAM Mo Zanaty (mzanaty) > 40cisco.com@dmarc.ietf.org> wrote: >> >> Perhaps we should limit Subgroup ID to a single byte. We made everything >> a varint by default for no good reason. Perhaps we should revisit all >> varint fields to rationalize if they truly need to be. >> >> Thanks, >> Mo >> >> >> ------------------------------ >> *From:* Ian Swett >> *Sent:* Sunday, May 3, 2026 10:38:30 PM >> *To:* Cullen Fluffy Jennings >> *Cc:* Magnus Westerlund ; >> MOQ Mailing List >> *Subject:* [Moq] Re: Knowing the start of a Subgroup >> >> Thanks for all the responses, particularly Mo's detailed response. >> >> I think we should move forward with the bitfield approach in #1618. >> >> I don't love that both Subgroup ID and Priority are ways of prioritizing >> Objects within a Group. At some point we agreed that priority should on= ly >> be a single byte. However, with Subgroup ID as well as priority, we now >> have a huge space. In practice, it probably doesn't matter, and I'm jus= t >> overthinking this. But it seems like there should be a way to >> simplify this part of the Object model without restricting any real-worl= d >> usecases. >> >> Thanks, Ian >> >> On Fri, May 1, 2026 at 6:14=E2=80=AFPM Cullen Fluffy Jennings >> wrote: >> >> >> >> > On Apr 30, 2026, at 9:08=E2=80=AFAM, Ian Swett w= rote: >> > >> > >> > If we go with the bitflag approach (#1618), are people ok with >> requiring it be set on the first Object in the Subgroup? Requiring it >> gives the feature a lot more value IMO. >> >> >> Yes, that makes sense to me. >> >> -- >> 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 > --0000000000004db775065103646f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What are the use-cases for a sub-group per object/datagra= m?=C2=A0

I think for media, it= would be sending each b-frame as a separate sub-group. What would be the i= deal prioritization there?

On Mon, May 4, 2026, 10:41=E2=80=AFAM Suhas= Nandakumar <suhasietf@gmail.com> wrote:
I think the question comes down to is the= re a use-case where we need more than 256 subgroups and needs to be conside= red for prioritization. I can't think of one, but love to hear from oth= ers.=C2=A0

On Mon, May 4, 2026 at 10:36=E2=80=AFAM Mo Zanaty (mzanaty) <m= zanaty=3D40cisco.com@dmarc.ietf.org> wrote:
If an app has no need for Subgroup ID semantic meaning, it can send an unli= mited number of objects as separate streams using the same ID (e.g. 0) and = reset-at. This seems really ugly, so I=E2=80=99d be willing to have a speci= al header type for single-object stream if that is a strong use case. I agree with the comments in I#1405 that thi= s may be closer to datagram than stream conceptually, which may motivate a = specific header type that merges the desired properties of datagram and str= eam.=C2=A0

If the stream-per-object case can be achieved without many subgroup IDs, th= en maybe a single byte is acceptable.=C2=A0

Thanks,
Mo


From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Sent: Monday, May 4, 2026 12:56:05 PM
To: Mo Zanaty (mzanaty) <mzanaty@cisco.com>
Cc: Cullen Fluffy Jennings <fluffy@iii.ca>; Magnus = Westerlund <magnus.westerlund@ericsson.com>= ;; MOQ Mailing List <moq@ietf.org>
Subject: Re: [Moq] Re: Knowing the start of a Subgroup
=C2=A0
I believe the concern with making Subgroup ID a single byt= e is if you wanted to do Object-per-Subgroup and couldn't or didn't= want to use datagrams, you'd be limited to 256 Objects per Group.

Otherwise, making Subgroup ID a byte a very appealing change.=C2=A0 Th= inking along those lines is what caused me to file #1405 (Single Object Subgroups don= 't need a Subgroup ID)

Ian


On Mon, May 4, 2026 at 12:24=E2=80=AFAM Mo Zanaty (mzanaty= ) <mzanaty=3D40cisco.com@dmarc.ietf.org> wrote= :
Perhaps we should limit Subgroup ID to a single byte. We made everything a = varint by default for no good reason. Perhaps we should revisit all varint = fields to rationalize if they truly need to be.=C2=A0

Thanks,
Mo


From: Ian Swe= tt <ianswett=3D40google.com@dmarc.ietf.org> Sent: Sunday, May 3, 2026 10:38:30 PM
To: Cullen Fluffy Jennings <fluffy@iii.ca>
Cc: Magnus Westerlund <magnus.westerlund=3D= 40ericsson.com@dmarc.ietf.org>; MOQ Mailing List <moq@ietf.o= rg>
Subject: [Moq] Re: Knowing the start of a Subgroup
=C2=A0
Thanks for all the responses, particularly Mo's detail= ed response.

I think we should move forward with the bitfield approach in #1618.

I don't love that both Subgroup ID and Priority are ways of priori= tizing Objects within a Group.=C2=A0 At some point we agreed that priority = should only be a single byte. However, with Subgroup ID as well as priority= , we now have a huge space.=C2=A0 In practice, it probably doesn't matter, and I'm just overthinking this.=C2=A0 = But it seems like there should be a way to simplify=C2=A0this part of the O= bject model without restricting any real-world usecases.

Thanks, Ian

On Fri, May 1, 2026 at 6:14=E2=80=AFPM Cullen Fluffy Jenni= ngs <fluffy@iii.ca> wrote:


> On Apr 30, 2026, at 9:08=E2=80=AFAM, Ian Swett <ianswet= t@google.com> wrote:
>
>
> If we go with the bitflag approach (#1618), are people ok with requiri= ng it be set on the first Object in the Subgroup?=C2=A0 Requiring it gives = the feature a lot more value IMO.


Yes, that makes sense to me.
--
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
--0000000000004db775065103646f--