Re: [V3] High level comments on the RIPT charter and scope

[Spencer Dawkins at IETF <[e-mail]>]

For what it's worth,

On Mon, Mar 30, 2020 at 8:44 AM Magnus Westerlund <magnus.westerlund=
[e-mail]> wrote:

> On Fri, 2020-03-27 at 10:19 -0600, Cullen Jennings wrote:
> >
> >
> > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
> > > magnus.westerlund=[e-mail]> wrote:
> > >
> > > The third big part is the media transport. I think we need to strongly
> > > consider
> > > if this can be broken out in to it seperate WG.
> >
> > I think the WG we are talking about here is the WG to do media of H3. So
> we
> > can talk about other things being in or out of it but that is the core
> thing.
> >
> > I would like to point out that one of the design properties that has been
> > making this easier is that media is self describing. What I mean by that
> is
> > that if a device receives media that is one of the supported formats and
> > within in the limits of that device supports, the media has all the
> > information the device needs to decode it. No out of band information
> needed.
> > That is key to making this easier to deal with HA and scalability on
> cloud
> > side. I think that is a good property for modern designs. We have been
> going
> > that way for a long time with things like opus and it works out well.
>
> So, let me ask a question here. How important is it be capable to transmitt
> individual media ADU or even RTP payloads in a single HTTP request that
> ripples
> through the system independent compared to have a system that can in a
> 0-rtt
> fashion (re-)establish an point to point by initiating an HTTP request?
>
> Treating each media ADU as its own request potentially being routed in a
> non-
> sticky way will induce significant jitter would it not? The drafts talks
> about
> sticky routing, and I did notice some comments about that assumption
> already.
> Thus, from my perspective it appears that the high-performance target
> would be
> to establish an point to point quic based transport with the relevant
> server
> node that handles media forwarding. If that fails have a mechanism that can
> rapidly re-establish that connection with what ever node that is now the
> appointed one for the given call/conference.
>
> Then I do understand the desire to have a fallback, and maybe that is
> plain HTTP
> requests, but let that be the fallback and not the primary mechanism.
> Becasue I
> think that would unnecessary limit the potential of this system.
>
> >
> > > here are several aspects here.
> > > First of the split in expertise between the media transport and the
> > > signalling
> > > folks.
> >
> > I’m not sure what you mean by signalling but the the singling here was
> mostly
> > start media , stop media. It is not call routing, forking etc that is
> done by
> > SIP.
>
> Yes, but even session establishment and control is still signalling from my
> perspective.
>

I've certainly been thinking of "everything except media payload" as
signaling in my own comments. So, close to Magnus here, IIUC.

If we don't have a common understanding of this (and it sounds like we
might not), that would be a good thing to talk about during the charter
development.

Best,

Spencer


> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
> --
> V3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v3
>