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

[Emad Omara <[e-mail]>]

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=
[e-mail]> 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 [phone]
> <+46%2073%20094%2090%2079>
> Torshamnsgatan 23           |
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>