Re: [Moq] Scope of MOQ and ULL Streaming

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 09 February 2023 15:54 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: moq@ietfa.amsl.com
Delivered-To: moq@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AFBC1575D9 for <moq@ietfa.amsl.com>; Thu, 9 Feb 2023 07:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPCeOcNFT8H2 for <moq@ietfa.amsl.com>; Thu, 9 Feb 2023 07:54:13 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACF0C151522 for <moq@ietf.org>; Thu, 9 Feb 2023 07:54:13 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id r18so1827332pgr.12 for <moq@ietf.org>; Thu, 09 Feb 2023 07:54:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LT06dm53ZFN9Cs8kx8bFlLzlyYauQMq+G80f65tHhpw=; b=hDBcnUgzLIwijtezz2fGRjAJcgXIse+Y0hlblql6tn/0zzOazJRFhlzWzZ0DmywkeM tsRgYPl1+onwpLPhKmS5Ix6WpUnbQTE1QDaO2iBU66zmOUC8pAq45o60vEWBT4MJm8sX L3Dhz7KplVeyJyitu3B8KXLpFoIsNdG6vIVOuL5d4+fpfvoK01kNIR0EGetkRX1di5FZ xBVptv0Y0OfEpzQHywTTTR9QQnZwAPjZsMoiHdDgnMmjAOIy9dkFvOUNcIjacIYF6S0D xli0Fl6XLg8vHi5lSIpYfuaw18amZTZPhoJMoTav0SRZsIu4cTqF6LhB4gB/gQx1oJ9i dGEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LT06dm53ZFN9Cs8kx8bFlLzlyYauQMq+G80f65tHhpw=; b=RfKm2PhvAhR5N/srKwNnQoF9thPsMGXlL+IAX5S6WyoxPh36vK6TwdrGkk2Ov+iZxx +deH8U3iJ59//NHoqMagbxP6azq45ItzBW5pTxwyPtUdG2UmCPTu4ZH+TCAjVOu4mPtq hquwi2aa84pLENcJk4cKAJ5+Lh6Kv+L3n8EqouRBJDTmasDOnreK5SnMDy9cZvV+2qXt k4QS7D74zGIeBEr5UcftoVmWjQaZZiG89Ma4GZtFwLSQ6Z/PmLN24O7jJKTTocdMBrFG M5D4T4KVy+SRJ8YdxuMBlW8v7btM+GUuKLjqQuvNB0p0v0g1TnWwqEPb0JgN8KAmYe2K O7Vw==
X-Gm-Message-State: AO0yUKVqbrYD00YkZ7iDLT0edJz18LMLcNRDgd7v0XOhGYP5O6Z0/0Nc WPgOKPdkuY8a654rO+q0yOs4zdJGnPEQ1CsDY8EFdKXj2UM=
X-Google-Smtp-Source: AK7set9S6XZmMz63PsBWSBCX0BEpS1g+juEZMMEbG6D3zfUAcHmwKGclqoqEI1HKDS2ruKEHgQMlUuPqTMS8fHKJhhU=
X-Received: by 2002:aa7:982d:0:b0:5a8:61cc:a860 with SMTP id q13-20020aa7982d000000b005a861cca860mr298569pfl.50.1675958052740; Thu, 09 Feb 2023 07:54:12 -0800 (PST)
MIME-Version: 1.0
References: <CAHVo=Z=uEAFrDGwgavO1r04oHCmL20M_rLzMtoAO59x8OuWKfw@mail.gmail.com> <E8696208-B33B-4C19-9D76-8563CA940265@gmail.com>
In-Reply-To: <E8696208-B33B-4C19-9D76-8563CA940265@gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 09 Feb 2023 09:53:46 -0600
Message-ID: <CAKKJt-et+8fXOzJDAhevquKmb0jmTGrHC729rZrTOhM2XKnZbw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Luke Curley <kixelated@gmail.com>, nathan.burr@paramount.com, "Shihang(Vincent)" <shihang9@huawei.com>, MOQ Mailing List <moq@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006466d805f4466401"
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/qtag76EADfbDVciy4hVN2E1Wwlw>
Subject: Re: [Moq] Scope of MOQ and ULL Streaming
X-BeenThere: moq@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Media over QUIC <moq.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/moq>, <mailto:moq-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/moq/>
List-Post: <mailto:moq@ietf.org>
List-Help: <mailto:moq-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/moq>, <mailto:moq-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2023 15:54:17 -0000

Hi, Bernard,

I agree with much of what's been said downthread, but wanted to poke at one
point that I haven't seen taken up.

On Wed, Feb 8, 2023 at 3:02 PM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> [BA] To have a shot at wide deployment, MoQ needs a “killer application”
> that can’t be delivered nearly as well by modifying HLS or DASH.  T*he
> requirements document doesn’t really focus on what that is, nor does it
> fully enumerate all the requirements MoQ would need to satisfy to fully
> differentiate itself in that usage. *
>

Improving the requirements document was our goal in presenting open issues
at last week's interim. But, beyond that, we are talking about questions
like deployment incentives that I haven't heard raised before - did I miss
that?

Where I think MOQ is, is that we agreed to charter MOQ for a minimum of
three use cases ("use cases including live streaming, gaming, and media
conferencing <https://datatracker.ietf.org/wg/moq/about/>") as a starting
point, we haven't written down the differences between those three use
cases, and we've been steadily removing attributes in the use cases section
of the requirements draft (so, no longer distinguishing among the use cases
based on latency, in the editor's version
<https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.html#name-use-cases-informing-this-pr>
).

My pre-interim plan (and also James Gruessing's plan, I think) was to focus
on high-level requirements that people working on WARP are uncovering, and
revisit the use cases later, when we could say something about additional
use cases that MOQ could support. We did get good feedback on requirements
during the interim (some during requirements draft discussions, and some
during WARP draft discussions), and I expect the design teams to also
provide helpful input as they do their work.

But I'm not sure the requirements draft would be the right place to put
discussion of deployment incentives, or Martin Duke's question, about how
someone knows that they should look at MOQ for their application, or keep
looking, because MOQ doesn't provide what they need. And there are probably
other useful questions to write down, and answer. (IMO, of course)

Does all that make sense?

Best,

Spencer