Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt

Jonathan Lennox <jonathan.lennox@8x8.com> Mon, 29 March 2021 16:28 UTC

Return-Path: <jonathan.lennox@8x8.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78223A1A26 for <avt@ietfa.amsl.com>; Mon, 29 Mar 2021 09:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNeBEbNxAjNZ for <avt@ietfa.amsl.com>; Mon, 29 Mar 2021 09:28:48 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D923A1A25 for <avt@ietf.org>; Mon, 29 Mar 2021 09:28:47 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id c3so12972703qkc.5 for <avt@ietf.org>; Mon, 29 Mar 2021 09:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8hJVqN1bPG2ntloBC61+uTcShJUpcs62f7hW9trNdUg=; b=W9XqOH4HPsNrm//V4AdZRsYd21aL/9e5PuIpZRji7RVfy7b1wXyYv1xCnFY1BAbfEU 5RxGvyDPLOfWC+KGutufIswR+VzlniJKSYOCKUhaSoJ81nCKPxFT7VFH13OZB0MFcsDE JX7BE/vU2lmTWIIR1Yn/LmGTR/LWWC/PgF7fk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8hJVqN1bPG2ntloBC61+uTcShJUpcs62f7hW9trNdUg=; b=s8INOfIeOMTRpECae54QuYdYn4crjRmKe8cKiIEFO2+gm9fVfBd5NymytPBiQRctGT Q5CDC/estPjdg6V/BTvQkbKTto3WsisW3p6PoK3B3eYbkp5IuG+/DtB9kMqWF9/ZLqAG BhEbrQV+cS76HB1yjFsU9dDEC9H2EFpRwtUMJuVG+sCwHBicZ9ZohbY0WiyIP/IGEIyU rvB1byRIXWTJ4el+rhTHGsZAkfR+DshmK8U51E6EKRppSMAMCylmgd0ymWiladTRwQTw xOwoTuWLjrQq4h0sPS2hDm0523AoDbi0nIbP4V5iU4J4LP8QWsO7Nqx9/gtGdew5z5rq 3aUg==
X-Gm-Message-State: AOAM532KoQ2TLjrQGG3Y5Ld5USI4SL/s3o86xj9U2vW1W/jASfC7+ECe KCzB6OVf75XgJoFFh7d0zlJEoQ==
X-Google-Smtp-Source: ABdhPJwvtUxbX+pS23eg7JSEPL7VZqXFbn0TCa4KgEcQ92LOupM9tR5sgPNlh8H46gkf0qiGb4nWEA==
X-Received: by 2002:a37:9e4e:: with SMTP id h75mr25808991qke.180.1617035324201; Mon, 29 Mar 2021 09:28:44 -0700 (PDT)
Received: from [192.168.2.243] (c-24-0-149-15.hsd1.nj.comcast.net. [24.0.149.15]) by smtp.gmail.com with ESMTPSA id a187sm13580151qkd.69.2021.03.29.09.28.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Mar 2021 09:28:43 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Jonathan Lennox <jonathan.lennox@8x8.com>
In-Reply-To: <AM0PR07MB3860002FE86CDF697C0062A8937E9@AM0PR07MB3860.eurprd07.prod.outlook.com>
Date: Mon, 29 Mar 2021 12:28:42 -0400
Cc: Justin Uberti <justin@uberti.name>, IETF AVTCore WG <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0940249-E81C-4655-8C04-6D565BED5A98@8x8.com>
References: <161227974389.17487.2345810476114650570@ietfa.amsl.com> <90619FEF-19AE-48B0-8C4C-D2A33870AA85@8x8.com> <AM0PR07MB3860C70B1DEA59A39F35375093B59@AM0PR07MB3860.eurprd07.prod.outlook.com> <DA91D9A6-519F-4FD0-8065-C95670D2DD00@8x8.com> <AM0PR07MB386022B8BD3BC62C949DA4B093B39@AM0PR07MB3860.eurprd07.prod.outlook.com> <561BE4F0-351A-41F5-B5EE-857779282637@8x8.com> <AM0PR07MB3860DF70547B8CEDBA70675F93999@AM0PR07MB3860.eurprd07.prod.outlook.com> <685618B1-A923-4AC5-A1CC-6229F4736D8E@8x8.com> <AM0PR07MB3860002FE86CDF697C0062A8937E9@AM0PR07MB3860.eurprd07.prod.outlook.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/adRl2rtAk2NRwJrENadpMUjYad0>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 16:28:53 -0000

There was one open issue that I’m not 100% sure we resolved in the WG meeting - whether a sender violating the signaled max-fs and max-fr is “SHOULD NOT” or “MUST NOT”.

In particular, in the spoken conversation we converged on “SHOULD NOT”, on the grounds that existing implementations are fine with it, and there are cases (like pre-encoded video or SFUs) where it’s helpful, but then Mo raised an concern in the chat (after the meeting itself had moved on) as to whether that would be a problem for hardware implementations, which are fairly rare now but might be more common going forward.

Because the spoken conversation and the minutes went with “SHOULD NOT”, I’ll submit an update with that unless I hear otherwise, but if you want to advocate for “MUST NOT” now’s the chance to do that.

> On Mar 29, 2021, at 6:53 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Any news on this?
> 
> Regards,
> 
> Christer
> 
> -----Original Message-----
> From: Jonathan Lennox <jonathan.lennox@8x8.com> 
> Sent: keskiviikko 3. maaliskuuta 2021 15.53
> To: Christer Holmberg <christer.holmberg@ericsson.com>
> Cc: Justin Uberti <justin@uberti.name>me>; IETF AVTCore WG <avt@ietf.org>
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt
> 
> The use cases I’m thinking about are things like SFUs, or pre-encoded video.
> 
> I guess the question is whether the semantics of max-fs and max-fr are “this is the maximum that is useful to me”, or whether they are “this is the maximum I am physically capable of”.
> 
> Browser vendors, what do your implementations do if they receive a stream violating the signaled max-fs or max-fr?
> 
>> On Mar 2, 2021, at 3:26 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 
>> Hi,
>> 
>> Thank you for the reply! You suggestions look good to me.
>> 
>> Regarding, Q4, I leave it up to you and other payload experts to decide whether it should be "SHOULD NOT" or "MUST NOT".  Is there a valid use case where one would use bigger values than have been indicated by the peer?
>> 
>> Regards,
>> 
>> Christer
>> 
>> -----Original Message-----
>> From: Jonathan Lennox <jonathan.lennox@8x8.com> 
>> Sent: tiistai 2. maaliskuuta 2021 17.45
>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>> Cc: Justin Uberti <justin@uberti.name>me>; IETF AVTCore WG <avt@ietf.org>
>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt
>> 
>> Hi, Christer — thanks again for your comments.
>> 
>> My response here is based on what I personally think would be the ideal solution; however, given that there is substantial amount of running VP9 code, if any of these would cause problems for the existing implementations it may need to be restricted.  If any browser implementors could check how their existing implementations handle SDP parameter updates in remote descriptions, that’d be very helpful.
>> 
>>> On Feb 4, 2021, at 1:48 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>> 
>>> Hi Jonathan,
>>> 
>>>>>> Q3:
>>>>> 
>>>>> Is there a reason why profile-id is optional, since a value will always be assumed?
>>>> 
>>>> Since profile-id negotiation was developed relatively late in the process of writing the spec, existing implementations don’t always send it.  It seemed best to maintain compatibility here.
>>> 
>>> Ok. Perhaps it would be useful to add a note indicating that?
>> 
>> Ok.
>> 
>>>>> Q2:
>>>>> 
>>>>> In Section 6.2.1, my understanding is that max-fs and max-fr are optional. Section 6.2.2 says that the answerer must maintain all configuration parameters. Does that apply to max-fs and max-fr too? If so, if the offer does not contain max-fs and max-fr, the answer cannot contain them either?
>>> 
>>> A little more on this: the draft says that max-fs and max-fr are only used to indicate capabilities. AFAIU, it is not used to negotiate anything, so I see no reason why endpoints would not be able to insert different values.
>> 
>> Yes, agreed.  I think the spec should say that each side MAY set max-fs and max-fr independently based on their own receiver capabilities, and these two parameters MAY be present in the answer even if they’re not present in the offer.
>> 
>> [Quoting from your previous e-mail:]
>>> Q4:
>>> 
>>> Section 6.2.2. does not define any restrictions on what can be modified in a subsequent offer, so I guess one can modify max-fs, max-fr and/or profile-id in a subsequent offer?
>> 
>> I would propose that profile-id MUST be maintained in subsequent offers (i.e., to negotiate a different profile-id, change payload type numbers), but max-fs and max-fr can be changed freely by either side.
>> 
>>> Also, Section 6.2.1 of the draft says:
>>> 
>>> "The parameters "max-fs", and "max-fr", MUST be included in the
>>>   "a=fmtp" line of SDP if SDP is used to declare receiver capabilities."
>>> 
>>> The "if SDP is used to declare receiver capabilities" sounds strange. Do you mean to say "MUST be included if the user wants to declare its receiver capabilities"?
>> 
>> Yes, that’s better wording.
>> 
>>> Also, there is no text on what an endpoint does when receiving those values by the peer. I assume the user should not exceed the indicated frame rate/size, but that is not specified anywhere.
>> 
>> Agreed.  An important question - should this be SHOULD NOT or MUST NOT?
>