Re: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09

["Asveren, Tolga" <[e-mail]>]

Thanks for the explanation, now it makes sense.

Thanks,
Tolga

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Thursday, September 10, 2015 4:42 PM
> To: Asveren, Tolga <[e-mail]>
> Cc: [e-mail]; Ali Begen <[e-mail]>
> Subject: Re: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-
> session-09
> 
> > On 10 Sep 2015, at 21:27, Asveren, Tolga <[e-mail]>
> wrote:
> >
> > Inline...
> >
> > Thanks,
> > Tolga
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[e-mail]]
> >> Sent: Thursday, September 10, 2015 1:57 PM
> >> To: Asveren, Tolga <[e-mail]>
> >> Cc: [e-mail]; Ali Begen <[e-mail]>
> >> Subject: Re: [AVTCORE] WGLC review on
> >> draft-ietf-avtcore-multi-media-rtp-
> >> session-09
> >>
> >> On 10 Sep 2015, at 17:55, Asveren, Tolga <[e-mail]>
> wrote:
> >>>>> The RTCP timing rules in RFC 3550 don't support different
> >>>>> reporting intervals for different SSRCs (other than a
> >>>>> sender/receiver split), and doing so runs a risk of causing
> >>>>> inappropriate RTCP timeouts. We could add a reference to RFC 3550
> here, if it helps?
> >>>> [TOLGA] Can't this be changed? On a high level, aren’t we talking about
> two different RTCP streams here? Why should their timing be aligned in any
> way?
> >>>
> >>> Their timing isn’t aligned, they merely use the same base RTCP reporting
> interval, before randomisation, and modulo the difference between sender
> and receiver bandwidth allocation. This is the usual RFC 3550 RTCP timing
> rules. If you want different reporting intervals, you need to use separate RTP
> sessions.
> >>> [TOLGA] I was also referring to reporting timing but admittedly not being
> clear. But then again, why should their timing be the same? Is there a
> technical justification or “just” because RFC3550 (which probably did not
> consider the use case defined/explained in this draft as it was not defined
> yet) says so?
> >>
> >> The technical justification is as I said above: you get inappropriate
> timeouts, because the algorithm is based on all SSRCs using the same base
> reporting interval.
> > [TOLGA] But that is exactly what I am asking, why can’t that be changed so
> that algorithm for different SSRCs are executed independently if multiple
> streams are multiplexed?
> 
> Because that wouldn’t be compatible with existing RTP. You’re essentially
> saying you want to run multiple RTP sessions in parallel on the same port, to
> get different RTCP timing behaviour for each media. That would be easy to
> implement if we’d chosen a shim-based approach, rather than the BUNDLE
> approach (and was one of the many reasons some of us advocated that). It
> doesn’t work with the single RTP session model we adopted, however. You’d
> have to partition the SSRC space for the different sessions, rewrite RTCP
> scheduling and timeout rules, collision resolution, etc. By the time you’ve
> done that, you have a whole new protocol, incompatible, and sharing little
> but the packet syntax with RTP.
> 
> Using RTP/AVPF with the T_rr_interval parameter gives a lot of flexibility, and
> you can almost certainly do something that has a similar effect to what you
> suggest using it, in a compatible way. Failing that, run multiple RTP sessions
> on different transport layer ports, and you have flexibility to use whatever
> different RTCP intervals you want.
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>