Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

Emad Omara <emadomara@google.com> Mon, 28 September 2020 22:30 UTC

Return-Path: <emadomara@google.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D923A143D for <dispatch@ietfa.amsl.com>; Mon, 28 Sep 2020 15:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 r_dvmpIdH9ex for <dispatch@ietfa.amsl.com>; Mon, 28 Sep 2020 15:30:14 -0700 (PDT)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 0586C3A0CB7 for <dispatch@ietf.org>; Mon, 28 Sep 2020 15:30:13 -0700 (PDT)
Received: by mail-vk1-xa32.google.com with SMTP id r78so1956242vke.11 for <dispatch@ietf.org>; Mon, 28 Sep 2020 15:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OmvVm0wGkgEBlAz+UXYmWo12R7M20Bvu2DH1fvA5//E=; b=Fh9emtLpmn8hatWETA7GydV2myo7btylrjmS8ytb6jBtMcEQDZcvPxJW4kMQ0Tle5h 4/+kYp00Ys5iCdXD1jS0WRLSofF5jAFm86/pfAXrcNwExvuiNDs0HnrshOcHWRfORctC e1JnpIH9MatusdTuvzCFW4+3DtZYq0DICGZh3J0OHh8wteWlYSBBCWydkb0D/gMxNmrd L/owtPx7i/PonlQ6d4aztIKFj5SREhzSLp4UHBKZkr8VjtmJpQOjsDuleQBATMfnZt8f v24uVnIGSukpGeV/USCdOtTovigz8zg5Nj1dJBKhNJzsPp7cLWAoIcMitTGiA/MBi2Wf 3zMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OmvVm0wGkgEBlAz+UXYmWo12R7M20Bvu2DH1fvA5//E=; b=VltOo8DauIPtZHn5zwoPWOZALnc/LU7G6zULJQVX5zd8OVbGt2UYj7438IgolTKkMx QBumLaHzxn4/Yk2R3C+dX4wwKkY2kILqkR83SAGs8H/f9/vRVA0mVHbgeXBlwq6mta/A ovkaQFWCxF9EjBSgd1X1XWBf1sz/EKpuXifNOz18Q06ZaIVdgwlaxlSsshLgmpCF0HqJ G3i2Y1PqV0l7XDbKrN+gr6Ts9q9rzCI4FerlXOFn38PsxP2Zg5wiL64cMUrDujzXs4mF Qi0mfnDNhfp7Ki7QupsW3RG/yp+SFz5hGVyAN7AjOjVbentShl1WJBCWF9GBpZYCruGL Mv7g==
X-Gm-Message-State: AOAM533xQobda/1w8i+FQXbTHr26kpv3POBaX484q9SiunwE4t7ndvZV BOXvfRhhPVulPtoklsLpovS3OLo3K8ZRJOJnGvFh
X-Google-Smtp-Source: ABdhPJznyRn37am7WCaCKwh7T6uyYFWaoSXU5H1hdG2lbtZyZk+MFsudjLWthJWOyomHMVdGl9NYOOojNSnErVshH40=
X-Received: by 2002:a1f:2d0c:: with SMTP id t12mr1151035vkt.0.1601332212713; Mon, 28 Sep 2020 15:30:12 -0700 (PDT)
MIME-Version: 1.0
References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <CAL02cgS=y7mBt10n+jCGwUoy54eeH9ZXFijQdDSKk5Qt9mNrUw@mail.gmail.com> <e0b5dc1c04ab6b5cee2c88b5b1b348d7c70a5d4c.camel@ericsson.com> <a3fbe87c-d60b-23f1-2968-c7ac6ad50ea4@cosmosoftware.io> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <HE1PR0702MB3772BEFD51DAB83AC64A252695240@HE1PR0702MB3772.eurprd07.prod.outlook.com> <cb46a294-5ae4-d82f-efe8-f887c578ae30@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> <d4179012-2d13-d48d-8805-a5b8747a47aa@gmail.com> <a6c19cb8e25006c78f674f3f4777442b376bf92b.camel@ericsson.com> <f21f0216-d3ae-832e-9648-d3283d7393aa@gmail.com> <c9153938b265081fb29fa46f12a2bafcbe9e9369.camel@ericsson.com>
In-Reply-To: <c9153938b265081fb29fa46f12a2bafcbe9e9369.camel@ericsson.com>
From: Emad Omara <emadomara@google.com>
Date: Mon, 28 Sep 2020 15:30:01 -0700
Message-ID: <CAHo7dC8nDxDkw8K20a9nG1_shaUWfDnWrR_wpAxnFdT8nRHWSw@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
Cc: "sergio.garcia.murillo@cosmosoftware.io" <sergio.garcia.murillo@cosmosoftware.io>, "rlb@ipv.sx" <rlb@ipv.sx>, "sergio.garcia.murillo@gmail.com" <sergio.garcia.murillo@gmail.com>, "dispatch@ietf.org" <dispatch@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "sframe@ietf.org" <sframe@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b52aa205b0673573"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/lSCR1VtJbtfhGhFdmqU7d_Vmg6Y>
Subject: Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2020 22:30:16 -0000

Hi Magnus,

Jumping late to this thread, just want to summarize the discussion and
proposed changes to make sure we are all on the same page.


   1. AVTCORE is the place to address any WebRTC changes (ie payload type,
   frame metadata ,packetization, etc)
   2. SFrame charter needs to be changed to explicitly mention #1
   3. SFrame doc needs to describe the integration point and changes with
   WebRTC in high level language as a guidance for the ATCORE work (I suggest
   doing so in a separate draft)

Would these address your concerns so we can move forward? Please let me
know if there is anything else I missed.

Thanks
Emad


On Tue, Sep 15, 2020 at 2:47 AM Magnus Westerlund <magnus.westerlund=
40ericsson.com@dmarc.ietf.org> wrote:

> On Mon, 2020-09-14 at 19:27 +0200, Sergio Garcia Murillo wrote:
> > On 14/09/2020 16:12, Magnus Westerlund wrote:
> > > Sergio,
> > >
> > > Having 20 years of experience with RTP payload format designs some of
> your
> > > formulations made me a bit worried. After this discussion I think we
> are
> > > much
> > > closer on a common understanding of the high level functionality
> necessary.
> > >
> > > However, there will be questions about where we document that
> interaction
> > > and
> > > what dependencies that do exist on other specificaitons for scalable
> codecs
> > > that
> > > are generic and is desirable to require from RTP middleboxes. In
> addition
> > > even
> > > without RTP there will be need from the application to consider how it
> can
> > > utilize one SFRAME key and its IVs to carry multiple application
> sub-streams
> > > and
> > > the need to expose that to lower layer transport function to achiveve
> > > performance goals.
> >
> > What I fail to understand is the nature of your concerns and how should
> we
> > address them on the charter:
> > Is it something that we plan to do that is not covered in the charter?
> > Is it something that we don't plan to do but the charter is wide enough
> to
> > allow it?
> > Is it something that we plan to do and it is covered in the charter but
> you
> > don't agree to it?
> > Is it something that we don't plan to do and is neither covered by the
> charter
> > and we should add it?
>
> I think with the resolution of the RTP payload format there is only the
> question
> if there needs to exist an informational discussion towards those who
> intended
> to apply the SFRAME format in their application the difference between
> application streams or strucutres and the SFRAME sequence and their keys
> and the
> requirement that puts on meta data and mapping to lower layer transport
> depending on application. I do note that a pure store and forward
> application
> like email has its set of needs that is quite different from real-time
> media.
>
> I personally would like to see it written into the charter that this needs
> to be
> considered. In the current draft update I think there wording that would
> imply
> that this needs to happen. However, depending on how the below change are
> done
> this might get lost.
>
> An alternative for the WG to actually ensure that they have a solid
> description
> and components that solve the issue would be to write an non-standard
> description of how SFRAME would be used in WebRTC multi-media multi-party
> with
> SFU conference application  and what is needed to make it work. There one
> could
> discuss the WebRTC applications control over how the media streams SFRAME
> encapsualtion and mapping onto RTP streams impact the underlying repair
> tools
> and SFUs of WebRTC conference application.
>
> If things are done correctly all the components, SFRAME, RTP Payload
> format, and
> meta deta transport would exist in specifications of their own, so that it
> could
> be that high level description of how an WebRTC application maker would
> get this
> to work avoiding those pitfalls that will exist.
>
> >
> > > So I think some clarification on the RTP payload format work, and it
> that is
> > > going to happen in the SFRAME WG. If happening in SFRAME WG I would
> like to
> > > have
> > > a joint WG Last call with AVTCORE WG.
> >
> > I raised that question already a couple of times. I am not sure what is
> the
> > role of the SFRAME WG regarding specifying a new RTP codec-agnostic
> payload.
> > IMHO this WG should collect the requirements, match them to current
> > specifications, and if anything is missing, liaise with the appropriate
> groups
> > in order to produce the specs based on our       requirements.
>
> Fine, lets make it explicit in a paragraph in the SFRAME WG charter that
> AVTCORE
> WG will be the place to do the work on the RTP Payload format and the WGs
> will
> colaborate on this.
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Mobile +46 73 0949079
> <+46%2073%20094%2090%2079>
> Torshamnsgatan 23           |
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
> --
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>