Re: [AVTCORE] My comments on draft-ietf-avtcore-rtp-circuit-breakers-08

[Magnus Westerlund <[e-mail]>]

On 2015-02-20 17:50, Colin Perkins wrote:
> Hi,
> 
> On 19 Feb 2015, at 08:06, Magnus Westerlund <[e-mail]> wrote:
> 
>> Hi,
>>
>> I have just reviewed the latest version of circuit breakers and have the
>> following feedback.
>>
>> I think the document has improved since I last reviewed it (-05) but I
>> think the following issue is not yet addressed from my previous review.
>>
>>> 7) Section 5:
>>>
>>> As there is a difference between CB #1 and #3 and #2 that has to do
>>> with that the first (#1 and #3) uses incoming RTCP reports and that #2
>>> uses the CB implementers estimate of what the regular reporting
>>> interval is. Thus, I wonder if there needs to exist include a
>>> reflection over t_rr_int as well as the RTCP SSRC timeout calculation
>>> that we recommend to use 5 seconds as fixed minimal value in those
>>> calculations (if 5 sec larger than t_rr_int).
>>
>> I will see if I can propose some text to address this.
> 
> I’m not sure how T_tt_interval affects the performance, so
> suggestions would be welcomed.

So the impact that T_rr_int has on the AVPF implementation is to
limiting the regular reporting (without any feedback) to no more often
than a randomized [0.5,1.5] of T_rr_int per reporting interval. As the
CB are based on the regular reporting, the choice of T_rr_int will
affect the CB behaviour.

Thus we have a potential issue with CB#2 and RTCP timeout. This breaker
must clearly take T_rr_int into account as that affect the RTCP regular
transmission interval. Thus, a media sender can't use its basic Td
calculation to determine how many reporting intervals that passed, i.e
this text from section 4.2:

   When
   calculating the timeout, the deterministic RTCP reporting interval,
   Td, without the randomization factor, and with a fixed minimum
   interval Tmin=5 seconds) SHOULD be used.  The rationale for this
   choice of timeout is as described in Section 6.2 of RFC 3550
   [RFC3550].


But, this could only be affected if T_rr_int is larger than 2,25
seconds. This is an approximation of where T_rr_int will result in any
potential longer reporting intervals than what Tmin = 5 does.

This approximation is based on the issue discussed in Section 6.1.1 of
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/

However, that case is a worst case and in fact Section 6.1.3 do
recommends a T_rr_int value of 4 for compatibility with AVP as that
balances the timeout issues in both directions if the AVPF does not
follow
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/
This value of T_rr_int will increase the chance of being timed out
following the above calculation slightly, and primarily in the case when
the bandwidth and participant numbers results in a Td close to T_rr_int.

Thus, I think one possible resolution is simply to forbid using T_rr_int
larger than 4 seconds in combination with circuit breakers.

> 
>> I also think there is need for scaling the number of reporting intervals
>> it takes to trigger the circuit breakers when using AVPF or reduced
>> minimum. Especially for AVPF there will be a lot of false triggering due
>> to relatively short time intervals that the circuit breakers will sample
>> over.
> 

> I think it’s clear we should scale the number of reporting intervals
needed to trigger the circuit breaker inversely with the duration of the
reporting interval, so it takes a roughly constant amount of time to
trigger. We need to write this up and simulate it’s performance.
> 
> Do you see RTP/AVPF impacting this differently to the impact of
> using the reduced minimum interval? (Or is this the T_rr_interval issue?)

T_rr_int will affect the number of reporting intervals one can expect
(statistically) during a certain time period within a given RTP session.
I think the scaling will resolve this potential concern as long as
T_rr_int is smaller than 4 seconds.

I would note that there is one difficulty for the scaling. If one has
bandwidth to have Td value of 0.1 seconds and a T_rr_int of 3 seconds,
then the number of actually sent regular reports will depend on how much
feedback one needed to send. Especially in combination with Reduced size
RTCP. Because if reduced size RTP is used for all early packets, then
the regular RTCP packets are the ones being counted towards the CB. And
RFC 4585 in Section 4.5.3 contains this implementation specific
behaviour when one has FB to send and comes upon a transmission point
with a T_rr_int != 0.

      2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB messages
          have been stored and are awaiting transmission, an RTCP packet
          MUST be scheduled for transmission at tn.  This RTCP packet
          MAY be a minimal or a Regular RTCP packet (at the discretion
          of the implementer), and the compound RTCP packet MUST include
          the stored RTCP FB message(s).  t_rr_last MUST remain
          unchanged.

Thus, the number of RTCP packets that contains RR or SR can and will
likely vary over a time interval even if the other parameters affecting
report interval is fixed.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------