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

"Ben Campbell" <ben@nostrum.com> Mon, 07 March 2016 22:51 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: avt@ietfc.amsl.com
Delivered-To: avt@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A895B1CDC6D; Mon, 7 Mar 2016 14:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRgFHrGoyFDV; Mon, 7 Mar 2016 14:51:16 -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 ietfc.amsl.com (Postfix) with ESMTPS id C535D1CDCA0; Mon, 7 Mar 2016 14:51:12 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u27Mp7AN072844 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 7 Mar 2016 16:51:08 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Colin Perkins <csp@csperkins.org>
Date: Mon, 07 Mar 2016 16:51:07 -0600
Message-ID: <56ACF11C-4B54-48B4-94D9-C14008358E1B@nostrum.com>
In-Reply-To: <E25B484A-8F46-4A79-94CF-062AE66BD315@csperkins.org>
References: <55B4CAAF-50FB-4111-82EE-3B40B0D9C2F4@nostrum.com> <E25B484A-8F46-4A79-94CF-062AE66BD315@csperkins.org>
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/OZjwj8xOL0B9Io8pyX1vAXaIyZk>
Cc: avt@ietf.org, draft-ietf-avtcore-rtp-circuit-breakers.all@ietf.org
Subject: Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 07 Mar 2016 22:51:17 -0000

Thanks for the response. Comments inline; I've deleted sections that 
don't seem to need further discussion.

Ben.

On 7 Mar 2016, at 12:36, Colin Perkins wrote:

[...]

>>
>>
>> Substantive
>> ===========
>>
>> -4, third paragraph, sentence starting with "This approach SHOULD NOT 
>> be used..."
>>
>> 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? :-)
>
> An RTP endpoint that implements the circuit breaker can’t talk to 
> non-RTCP peers unless the circuit breaker is disabled, since the lack 
> of RTCP will trigger the RTCP timeout circuit breaker. This sentence 
> says you SHOULD NOT disable the RTP circuit breaker to talk to 
> non-RTCP peers, unless you have some other means of determining 
> whether you’re causing excessive congestion.

My concern is the interaction with the SHOULD NOT in paragraph 3, which 
says the non RTPC peer SHOULD NOT be on the network in the first place, 
unless you have another way to report congestion. Do you consider the 
"unless you have other means..." parts to be exhaustive? That is, are 
they the only circumstances in which one might violate the SHOULD? If 
that's the case, then both should probably say "MUST NOT... unless you 
have some other means...".

On the other hand, if the intent is really mean SHOULD NOT, which would 
allow implementors to find other "good reasons" to violate it, then we 
end up with the situation where a non-RTCP peer chooses to join the 
network for some "other good reason", but other peers that support 
circuit-breakers will not honor that choice. The point is, we probably 
don't need both SHOULD NOTs. And since implementations that do not 
implement rtcp are also unlikely to implement _this_ draft, it probably 
makes more sense to keep the one in paragraph 4.

>
>> -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?
>
> Assuming you mean last paragraph of §4.1,

Yes, sorry.

> the reason I’m hesitant to say that it always applies is due to 
> draft-ietf-tsvwg-rtcweb-qos-13 allowing different DSCP markings on 
> different RTP flows on a 5-tuple, making me wonder if there could be 
> differential queuing meaning the circuit breaker could trigger for RTP 
> flows but not for others. Aside from that, it’s safe to always 
> behave that way.

I guess my concern is that "In this case..." can be interpreted to mean 
the sender should choose or not choose this behavior based on inferences 
about whether the receiver's RR packets will be too big. Is it 
reasonable to expect the sender to draw that inference?  (Or would it 
make sense to chance "In this case..." to "For this reason..."?)

>
>> How does this relate to the guidance (MAY) in section 8?
>
> I guess you could treat this as one example of treating flows as a 
> group. If the DSCP issue noted above is a concern, it might make sense 
> to update Section 8 to say you can treat RTP flows of the same media 
> type (audio, video, etc.) as a group, rather than any subset of RTP 
> flows.

So the point would be that the receiver MAY always treat flows as a 
group, and SHOULD do so if it thinks the RRs would be too big? I guess 
that makes sense, depending on your answer about whether the sender can 
reasonably infer that.

[...]

>
>> -4.4, 2nd to last paragraph, last sentence:
>>
>> Is there any potential guidance on reasonable lower limits to the 
>> time period considered “significant"?
>
> Several seconds, and perhaps tens of seconds.

Does it make sense to say that in the text?

>
>> - 12.2:
>>
>> It seems like the following references might should be normative: 
>> I-D.ietf-tsvwg-circuit-breaker, RFC3168, RFC6679
>
> I think you can implement the RTP circuit breaker without reading any 
> of those, so informative seems correct. However, I don’t much care 
> either way.

On reflection I agree for tsvwg-circuit-breaker and RFC 3168. However, 
section 7 seems to describe an optional feature that depends on RFC 
6679. IMO, normative dependences, even in optional features, need a 
normative reference.



>
>> Editorial
>> =========

[...]

>
>> -- 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?)
>
> Correct. Perhaps “MUST record the value of the fraction lost field 
> from the report block” would be clearer?
>

It seems more clear to me.

[...]