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

[Magnus Westerlund <[e-mail]>]

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]
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------