Re: [AVTCORE] RFC4585: AVPF scheduling issue

[Magnus Westerlund <[e-mail]>]

WG,

An complementary action we could do about this is to rewrite some 
already existing text in draft-ietf-avtcore-rtp-multi-stream to make 
clear that this interpretation. Because this interpretation was written 
into the document already before:

Section 6.1.1, first paragraph:

    The RTP/AVPF profile includes a method to prevent RTCP reports from
    being sent too often.  This mechanism is described in Section 3.5.3
    of [RFC4585], and is controlled by the T_rr_interval parameter.  It
    works as follows.  When a regular RTCP report is sent, a new random
    value, T_rr_current_interval, is generated, drawn evenly in the range
    0.5 to 1.5 times T_rr_interval.  If a regular RTCP packet is to be
    sent earlier then T_rr_current_interval seconds after the previous
    regular RTCP packet, and there are no feedback messages to be sent,
    then that regular RTCP packet is suppressed, and the next regular
    RTCP packet is scheduled.  The T_rr_current_interval is recalculated
    each time a regular RTCP packet is sent.  The benefit of suppression
    is that it avoids wasting bandwidth when there is nothing requiring
    frequent RTCP transmissions, but still allows utilization of the
    configured bandwidth when feedback is needed.

What is the WG's opinion about making this clarification in this document?

Cheers

Magnus Westerlund
(As document author)

Magnus Westerlund skrev den 2015-05-25 15:23:
> WG,
>
> Sebastian Dröge noticed an issue with the T_rr_interval suppression
> algorithm as written in Section 3.5.3 in RFC 4585.
>
> Quoting the relevant text:
>
>     If T_rr_interval != 0, then the calculation for the transmission
>     times MUST follow the rules as specified in Sections 3.2 and 3.4 of
>     this document and MUST adhere to the adjustments of tn specified in
>     Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP
>     transmission has occurred).  Timer reconsideration takes place when
>     tn is reached as per [1].  After timer reconsideration, the following
>     actions are taken:
>
>     1. If no Regular RTCP packet has been sent before (i.e., if t_rr_last
>        == NaN), then a Regular RTCP packet MUST be scheduled.  Stored FB
>        messages MAY be included in the Regular RTCP packet.  After the
>        scheduled packet has been sent, t_rr_last MUST be set to tn.  Tmin
>        MUST be set to 0.
>
>     2. Otherwise, a temporary value T_rr_current_interval is calculated
>        as follows:
>
>           T_rr_current_interval = RND*T_rr_interval
>
>        with RND being a pseudo random function evenly distributed between
>        0.5 and 1.5.  This dithered value is used to determine one of the
>        following alternatives:
>
>
> So Sebastian asked me if one really should do the randomization (in Step
> 2 above) each time Tn has expired and after reconsideration resulted in
> that one should evaluate if T_rr_interval will suppress this regular
> transmission.
>
> To my understanding that is not the intended, as it will result in that
> the suppressed interval between RTCP packets (given that T is
> significantly smaller than T_rr_interval) will be heavily skewed towards
> the lower boundary value of 0.5*T_rr_interval rather than being
> uniformly distributed between 0.5 and 1.5 times T_rr_interval.
> Considering that these randomization is there to avoid inter
> transmission synchronization ending up in something that skews and
> compresses the range of randomization appears to be wrong.
>
> Thus, from my perspective, there are no doubt that the randomization of
> T_rr_current_interval should only occur once per transmission of regular
> RTCP packet.
>
> Thus, I would like to see if you in the WG agrees with this
> interpretation of RFC 4585. If you do we should prepare an Errata to
> ensure that people do not misunderstand this.
>
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>


-- 

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