[AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13

"Ben Campbell" <ben@nostrum.com> Wed, 24 February 2016 22:19 UTC

Return-Path: <ben@nostrum.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 A84F21B4066; Wed, 24 Feb 2016 14:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2CSvfq41hgGF; Wed, 24 Feb 2016 14:19:40 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9B28E1B4057; Wed, 24 Feb 2016 14:19:40 -0800 (PST)
Received: from [] (cpe-70-119-203-4.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1OMJc5D054433 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 24 Feb 2016 16:19:39 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [] claimed to be []
From: Ben Campbell <ben@nostrum.com>
To: draft-ietf-avtcore-rtp-circuit-breakers.all@ietf.org, avt@ietf.org
Date: Wed, 24 Feb 2016 16:19:38 -0600
Message-ID: <55B4CAAF-50FB-4111-82EE-3B40B0D9C2F4@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5226)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/RVAOMdE0El3Ru4KbFHg-zSmT6iU>
Subject: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 24 Feb 2016 22:19:42 -0000


This is my AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13. 
While I do have some comments and questions, I don't think anything here 
needs to block IETF last call. Please address these along with any other 
last call feedback.




-4, third paragraph, sentence starting with "This approach SHOULD NOT be 

Does this mean that, in addition to the fact that non-RTCP peers 
shouldn’t be on the network in the first place, a circuit-breaker 
implementation shouldn’t talk to them even if they are? That is, even 
if the peer has a "good reason" (in an RFC 2119 sense) to violate that 
SHOULD, circuit-breaker implementations should ostracize it? :-)

-4.2, last paragraph, sentence starting with "In this case"

Does this imply that the SHOULD only applies if the sender has reason to 
believe that the SR or RR packets will be too large? or should the 
sender always behave this way?

How does this relate to the guidance (MAY) in section 8?

- 4.3, 6th paragraph:"Implementations that desire this extra sensitivity 
MAY use the full TCP throughput equation in the RTP circuit breaker. "

Is there potential for the extra sensitivity to do harm (beyond the 
higher calculation complexity)?

-4.4, 2nd to last paragraph, last sentence:

Is there any potential guidance on reasonable lower limits to the time 
period considered "significant"?

- 12.2:

It seems like the following references might should be normative: 
I-D.ietf-tsvwg-circuit-breaker, RFC3168, RFC6679


- Abstract
s/"will deteriorate"/"will cause the deterioration of"
-- "This acts as a safety measure..."
What is the antecedent for “this”? Congestion control? The 
deterioration? (Also, this sentence contains a comma splice)

- 1:
A very short definition of what we mean by "circuit breaker" might be 

- 3:
It's a little odd to find 2119 keywords imbedded in term definitions. 
You might consider moving those to procedure sections. (OTOH, it may not 
be worth changing this late in the process.)

-4.2, last paragraph:
What would it even mean to maintain a timeout past the end of the 
related stream?


-- paragraph 6:
typo: s/throughout/throughput

-- paragraph 9: "MUST record the value of the fraction
    lost field in the report block"

Does this mean the field _from_ the report block? (That is, you aren't 
_writing_ the value in the report block?)

-9, last paragraph:

Is this paragraph really related to security? It sounds more like an 
operational consideration.