[AVTCORE] draft-ietf-avtcore-rtp-circuit-breakers-02

Colin Perkins <csp@csperkins.org> Sun, 10 March 2013 20:16 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A433D21F8873 for <avt@ietfa.amsl.com>; Sun, 10 Mar 2013 13:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0bFEJL-GiQ3 for <avt@ietfa.amsl.com>; Sun, 10 Mar 2013 13:16:20 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13E21F8869 for <avt@ietf.org>; Sun, 10 Mar 2013 13:16:20 -0700 (PDT)
Received: from [130.129.134.52] (port=50758) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UEmfC-0004Tm-4o for avt@ietf.org; Sun, 10 Mar 2013 20:16:10 +0000
From: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 10 Mar 2013 16:16:07 -0400
Message-Id: <BF146FD1-69AA-4063-B946-CE0F1A13354C@csperkins.org>
To: "avt@ietf.org WG" <avt@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Subject: [AVTCORE] draft-ietf-avtcore-rtp-circuit-breakers-02
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 10 Mar 2013 20:16:21 -0000

We submitted an update to the RTP circuit breakers draft just before the cut-off, and I'll be presenting and discussing it in AVTCORE on Tuesday. The significant changes in the -02 version are:

- Disallow rate reduction by a factor of 10 as a response when the media timeout circuit breaker is triggered. A media timeout (several reporting intervals when media is being set but not received) signals a significant path failure, rather than a transient problem, and so should stop the RTP media flow, not just reduce it's rate.

- Clarify RTCP Timeout circuit breaker, and note that the fixed minimum RTCP reporting intervals SHOULD be used when calculating the RTCP timeout based on the rationale in Section 6.2 of RFC 3550.

- Clarify that the congestion circuit breaker uses the reduced minimum interval, rather than the fixed minimum interval, if it's in use in the RTP session. The reduced minimum interval scales with the data rate and so matches the dynamics of the congestion circuit breaker.

- Break the description of what it means to cease transmission into a
separate section, and expand. Clarify that we look at the destination 3-tuple (transport, port, IP addr) rather than the full 5-tuple when
deciding when to restart (to prevent someone thinking it's okay
to simply change the source port, and try again)

- Clarify that reduced-size RTCP packets containing RTCP SR or RR packets sent under the RTP/AVPF rules MUST be counted towards the circuit breaker conditions. Reduced size RTCP packets that don't contain SR or RR packets are not counted towards the circuit breaker.  These rules are intended to allow the use of low-overhead early RTP/AVPF feedback for generic NACK messages without triggering the RTP circuit breaker.  This is expected to make such feedback suitable for RTP congestion control algorithms that need to quickly report loss events in between regular RTCP reports.  The reaction to reduced-size RTCP SR/RR packets is to allow such algorithms to send feedback that can trigger the circuit breaker, when desired.

- Expand discussion of how and when ECN-CE marks are counted towards the
circuit breaker. RFC 6679 provides RTCP extensions to feed back ECN-CE marks in RTCP XR, and these are counted towards the circuit breaker. ECN-CE marks reported in a reduced size RTCP packet along with an SR or RR block are processed; if the SR or RR block is not present, they're ignored.


In addition, there are a number of minor changes:

- Update title and abstract

- Explain why multicast circuit breakers are out of scope

- Explain why the numbers of SSRCs might be greater than two in a unicast RTP session

- Note that RTCP is an essential part of the RTP protocol, and that the circuit breaker cannot be used if RTCP is not implemented. Clarify that implementations that don't have a circuit breaker (or equivalent) SHOULD NOT be used on networks that might be subject to congestion.

- Clarify that the RTCP RR jitter estimate is only valid where each RTP packet comprises one complete frame of media (i.e., the estimate is not valid if a frame gets split across multiple RTP packets with the same timestamp).

- Expand discussion of competition with TCP flows

- Clarify operation of congestion circuit breaker if the fraction lost is
zero

- Clarify that the circuit breaker at a sender only looks at RTCP SR/RR packets that contain reports for the SSRC values it is using to send



-- 
Colin Perkins
http://csperkins.org/