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

[Colin Perkins <[e-mail]>]

> 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/