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

Colin Perkins <> Mon, 13 June 2016 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 140A312DA33 for <>; Mon, 13 Jun 2016 14:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QA3JNWEYj6er for <>; Mon, 13 Jun 2016 14:05:51 -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 714D412DA2E for <>; Mon, 13 Jun 2016 14:05:51 -0700 (PDT)
Received: from [] (port=33725 helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bCZ3M-0006aA-MH; Mon, 13 Jun 2016 22:05:49 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 13 Jun 2016 22:05:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: IETF AVTCore WG <>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <>
Cc: "Mirja Kuehlewind \(IETF\)" <>, Stephen Farrell <>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-16.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: Mon, 13 Jun 2016 21:05:55 -0000

This version contains three sets of changes:

- Editorial changes to the Abstract and Introduction, to address Stephen Farrell’s comment by clarifying what it means to “operate within the envelope defined by this memo". 

- Update Section 4.5 (“Ceasing Transmission”) to address Alissa Cooper’s DISCUSS, clarifying that it is the RTP flows sharing a 5-tuple that are stopped when the circuit breaker triggers, rather than the entire call.

- Update Section 7 to address Mirja Mühlewind’s DISCUSS, expanding the discussion of how the RTP circuit breaker should react to ECN-CE marks. This changes “ECN-CE marked packets SHOULD be treated as if they were lost when calculating if the congestion-based RTP circuit breaker” into a more nuanced recommendation, based on likely future evolution of ECN response.

This changes the normative requirements of the specification, so a brief new WG last call is likely needed. 


> On 13 Jun 2016, at 21:46, 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-16.txt
> 	Pages           : 26
> 	Date            : 2016-06-13
> 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.  To avoid triggering the RTP
>   circuit breaker, any standards-track congestion control algorithms
>   defined for RTP will need to operate within the envelope set by these
>   RTP circuit breaker algorithms.
> 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