Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-14.txt

Colin Perkins <> Thu, 17 March 2016 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09ACF12D953 for <>; Thu, 17 Mar 2016 06:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H9Mhgb4P8nGM for <>; Thu, 17 Mar 2016 06:53:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E98A812D93C for <>; Thu, 17 Mar 2016 06:53:35 -0700 (PDT)
Received: from [] (port=65052 by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1agYMm-0000Is-UE; Thu, 17 Mar 2016 13:53:34 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Thu, 17 Mar 2016 13:53:25 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: IETF AVTCore WG <>
X-Mailer: Apple Mail (2.3112)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-14.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Mar 2016 13:53:39 -0000

This version is intended to address AD and OPS Dir review comments. The changes are:

- Rewrite the Abstract, and update Section 1 to clarify what is meant by a circuit breaker.

- In Section 4, clarify that the RTP circuit breaker SHOULD NOT be disabled on networks that might be subject to congestion, even if the peer doesn’t support RTCP, unless there is some other way of detecting congestion.

- In Section 4.3, clarify what information is recorded when RTCP SR/RR report blocks are received.

- In Section 4.4, clarify that the time period that is considered significant is on the order of seconds, of 10s of seconds.

- In Section 4.5, add a paragraph to suggest that implementations might monitor RTCP reception reports, to warn that problems are occurring, before the RTP circuit breaker triggers.

- In Section 8, expand discussion of grouping when different DSCP values are used in a bundled group.

- Move RFC6679 to be a normative reference, rather than informative

There are also a number of minor editorial corrections.


> On 17 Mar 2016, at 13:36, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Audio/Video Transport Core Maintenance of the IETF.
>        Title           : Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
>        Authors         : Colin Perkins
>                          Varun Singh
> 	Filename        : draft-ietf-avtcore-rtp-circuit-breakers-14.txt
> 	Pages           : 24
> 	Date            : 2016-03-17
> Abstract:
>   The Real-time Transport Protocol (RTP) is widely used in telephony,
>   video conferencing, and telepresence applications.  Such applications
>   are often run on best-effort UDP/IP networks.  If congestion control
>   is not implemented in these applications, then network congestion can
>   lead to uncontrolled packet loss, and a resulting deterioration of
>   the user's multimedia experience.  The congestion control algorithm
>   acts as a safety measure, stopping RTP flows from using excessive
>   resources, and protecting the network from overload.  At the time of
>   this writing, however, while there are several proprietary solutions,
>   there is no standard algorithm for congestion control of interactive
>   RTP flows.
>   This document does not propose a congestion control algorithm.  It
>   instead defines a minimal set of RTP circuit breakers: conditions
>   under which an RTP sender needs to stop transmitting media data, to
>   protect the network from excessive congestion.  It is expected that,
>   in the absence of long-lived excessive congestion, RTP applications
>   running on best-effort IP networks will be able to operate without
>   triggering these circuit breakers.  Future RTP congestion control
>   specifications will be expected to operate within the constraints
>   defined by these circuit breakers.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> Audio/Video Transport Core Maintenance

Colin Perkins