[AVTCORE] RFC4585: AVPF scheduling issue

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 25 May 2015 13:23 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6561A8A4E for <avt@ietfa.amsl.com>; Mon, 25 May 2015 06:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMiHkhrxk1M2 for <avt@ietfa.amsl.com>; Mon, 25 May 2015 06:23:22 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0751A8A63 for <avt@ietf.org>; Mon, 25 May 2015 06:23:18 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-07-55632243f092
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.4A.28096.34223655; Mon, 25 May 2015 15:23:15 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.210.2; Mon, 25 May 2015 15:23:15 +0200
Message-ID: <55632243.8030501@ericsson.com>
Date: Mon, 25 May 2015 15:23:15 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IETF AVTCore WG <avt@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3VtdZKTnUYOJ3a4uXPSvZLQ53L2Z0 YPJY2/ORzWPJkp9MAUxRXDYpqTmZZalF+nYJXBmfL/1kKjgvVjH7QAt7A+N9wS5GDg4JAROJ LVNiuhg5gUwxiQv31rN1MXJxCAkcZZQ4NaWZBcJZzijx7nkjG0gVr4C2xIXd/ewgNouAqsTx BfNZQGw2AQuJmz8gakQFoiSmPl7HAlEvKHFy5hMwW0RASWLHpG3MIDazgIvE9r4DYLawgLrE nzePGUEOYhawl3iwtQyiRF6ieetssBIhoLUNTR2sExj5ZyGZOguhYxaSjgWMzKsYRYtTi4tz 042M9FKLMpOLi/Pz9PJSSzYxAkPv4JbfVjsYDz53PMQowMGoxMOr0JQUKsSaWFZcmXuIUZqD RUmc17MrJFRIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo/4T7TUnZt6piL0q3z/Jhl/Z/05M ie29cyll+3bvbnN4mC1x9yd7izdjYpCU7pvb/L7HOxr9/+5Y9Y1thgHrosNrS9UTv0W3G85f aTlV6QTzg/lfHgZWbJyXYvn7SvaZV683pU3pNbQTM1730/Ldj4c1XxcsvqpwJPeV73+RVwmf 160Kes6ay6fEUpyRaKjFXFScCACegVq6HgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/r1jI-ZoHzs5RSMdvm6_ZowvwEPg>
Cc: =?windows-1252?Q?Sebastian_Dr=F6ge?= <sebastian@centricular.com>
Subject: [AVTCORE] RFC4585: AVPF scheduling issue
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2015 13:23:26 -0000

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------