Re: [AVTCORE] RFC4585: AVPF scheduling issue

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 01 June 2015 09: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 6F30C1A90E7 for <avt@ietfa.amsl.com>; Mon, 1 Jun 2015 02:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5XdcvVYAB69k for <avt@ietfa.amsl.com>; Mon, 1 Jun 2015 02:23:36 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAA91A90E1 for <avt@ietf.org>; Mon, 1 Jun 2015 02:23:36 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-a5-556c24965d97
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F1.03.04401.6942C655; Mon, 1 Jun 2015 11:23:34 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Mon, 1 Jun 2015 11:23:33 +0200
Message-ID: <556C2495.2010704@ericsson.com>
Date: Mon, 1 Jun 2015 11:23:33 +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>
References: <55632243.8030501@ericsson.com>
In-Reply-To: <55632243.8030501@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvre40lZxQg+P3pSxe9qxktzjcvZjR gcljbc9HNo8lS34yBTBFcdmkpOZklqUW6dslcGW8enqfueCXesWn/U1sDYzH5bsYOTkkBEwk 5v77zAZhi0lcuLceyObiEBI4yijxa/1xRghnGaPEx9NPmUCqeAW0Jd6cOcoCYrMIqEisXDyT HcRmE7CQuPmjEWySqECUxNTH61gg6gUlTs58AmaLCChJ7Ji0jRnEZhZwkdjedwDMFhYwlfh9 4zGYLQQ0v2/aFLB6TgEdif+P2lm7GDmA6u0lHmwtg2iVl2jeOhuuvKGpg3UCo+AsJNtmIXTM QtKxgJF5FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgsB7c8lt1B+PlN46HGAU4GJV4eBfs yQ4VYk0sK67MPcQozcGiJM7r2RUSKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR6Ht7/pyg be0SkzuU1ZNnK9qw/1N+4BtSos3B+umZWRbH2bTs06sM/7dOcFy4crYxp7top93KxI3ncgpi Vh69OHdGV36AvP6MWsPJm04uurY70H5xs9LZFbXCFu0rTBze5Z24yHBmv6cIv1G023+76QFe HlUfp4k+1Thws086OLa+5f3zWF4lluKMREMt5qLiRAA6OBwTNwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/ddHur7sw_uB8Fs-eQ0UXVfHeKQo>
Cc: =?windows-1252?Q?Sebastian_Dr=F6ge?= <sebastian@centricular.com>
Subject: Re: [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, 01 Jun 2015 09:23:38 -0000

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  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


-- 

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