[AVTCORE] Review of draft-ietf-avtcore-rtp-circuit-breakers-10

Simon Perreault <sperreault@jive.com> Fri, 08 May 2015 16:47 UTC

Return-Path: <sperreault@jive.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D62B71A87BF for <avt@ietfa.amsl.com>; Fri, 8 May 2015 09:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ms32Xr1G9-vF for <avt@ietfa.amsl.com>; Fri, 8 May 2015 09:47:19 -0700 (PDT)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA681A1A7F for <avt@ietf.org>; Fri, 8 May 2015 09:47:19 -0700 (PDT)
Received: by qcyk17 with SMTP id k17so39937837qcy.1 for <avt@ietf.org>; Fri, 08 May 2015 09:47:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=CESJT7y8vocviqc88/xm4PzPADRnzQYMqgf5s8C/xCA=; b=Qv5TR0jVLLwZkb28QxvYFuYTfQ/OdIpP9mTV6cmfQI26ntLMO0Ng2DZRorWPgyte9Y h8ATeZBkoLxC8V6b5Ek0jZAkWdgOh7RtVSn/LoAWRya8LCrUtJD+dyznHK6haLOtbOKX ipdOjl9OvH1bHX+u+ty5TVyFdeSYT1We937Dq9dQ/qLVOX+NmTsJMd1bb4ZGb7R5tOkd pu24+DKbNONV0Mw4jGTvAiANImMLBQ6Cbi+cnVn5OFuoA4C9REn9YX1JPXAg0AK0aWt0 Mr938wbk1/eL/y12O48KX1zsWvjXY3xOZ4DufPTgzGkYH6XKdWjkMguKrE4lf2GQe+2w oxSA==
X-Gm-Message-State: ALoCoQlnuJBTHX2/XKr1LhcVJh7uDSshD8asVF1iuwRDt6P6Mz6U28zmbaUxETpfHNlDL2qaIP9R
X-Received: by with SMTP id f87mr10147834qkf.38.1431103638460; Fri, 08 May 2015 09:47:18 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPSA id t33sm3978718qge.19.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2015 09:47:17 -0700 (PDT)
Message-ID: <554CE893.7050006@jive.com>
Date: Fri, 08 May 2015 12:47:15 -0400
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: draft-ietf-avtcore-rtp-circuit-breakers@tools.ietf.org, "avt@ietf.org" <avt@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/eaAbeP8LP9z3aK8cHNHWiVWcvTg>
Subject: [AVTCORE] Review of draft-ietf-avtcore-rtp-circuit-breakers-10
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: Fri, 08 May 2015 16:47:21 -0000

Authors, WG,

I read draft-ietf-avtcore-rtp-circuit-breakers-10 as a probable
implementer. Questions follow.

In general this is an exceptionally well written draft. I especially
enjoyed the amount and quality of background information and rationale
text. And I have zero grammatical nits to report!



In section "4.  RTP Circuit Breakers for Systems Using the RTP/AVP Profile":

>    RTCP is a fundamental part of the RTP protocol, and the mechanisms
>    described here rely on the implementation of RTCP.  Implementations
>    that claim to support RTP, but that do not implement RTCP, cannot use
>    the circuit breaker mechanisms described in this memo.  Such
>    implementations SHOULD NOT be used on networks that might be subject
>    to congestion unless equivalent mechanisms are defined using some
>    non-RTCP feedback channel to report congestion and signal circuit
>    breaker conditions.

Ok, fine, but how should *my* supposedly well-behaving implementation
deal with those bad implementations? Status quo (i.e., no circuit breaker)?

Absent a priori knowledge of the remote endpoint's RTCP capabilities,
would it be OK to arm circuit breakers upon reception of a first RTCP


In section "4.1.  RTP/AVP Circuit Breaker #1: Media Timeout":

>    The extended highest sequence number received field is non-increasing
>    if the sender receives at least CB_INTERVAL consecutive RTCP SR or RR
>    packets that report the same value for this field, but it has sent
>    RTP data packets, at a rate of at least one per RTT, that would have
>    caused an increase in the reported value if they had reached the
>    receiver.

How would "at a rate of at least one per RTT" be implemented in
practical terms, keeping in mind that both the sending rate and the RTT
vary during a session? Must the condition be satisfied all of the time
or only part of the time? For example, what should happen when the
condition is satisfied for all but one of the CB_INTERVAL RTCP reports?
As an implementer, I need more guidance here.

Also, I assume that RTT is to be estimated from RTCP as usual, but it
would help to be explicit about this.

Section "4.3.  RTP/AVP Circuit Breaker #3: Congestion" also uses the
"more than one RTP packet per RTT" condition, so my comments also apply


About section "4.4.  RTP/AVP Circuit Breaker #4: Media Usability"...

Would it be appropriate for an interactive RTP receiver (e.g., a soft
phone) to simply rely on the user hanging up the call? If so, it would
be nice to spell it out for implementers.

Similarly, would it be OK when sending to an interactive RTP receiver to
rely on the receiver hanging up, instead of guessing what might be
usable or not?

More generally, why should senders implement this circuit breaker at
all? Why not always rely on the receiver?