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

Colin Perkins <csp@csperkins.org> Wed, 16 March 2016 15:12 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 5750712D8A8; Wed, 16 Mar 2016 08:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCP7gNuLi24b; Wed, 16 Mar 2016 08:12:31 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013F412D8C7; Wed, 16 Mar 2016 08:12:21 -0700 (PDT)
Received: from [130.209.247.112] (port=56446 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1agD7R-0002tD-PY; Wed, 16 Mar 2016 15:12:18 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <56ACF11C-4B54-48B4-94D9-C14008358E1B@nostrum.com>
Date: Wed, 16 Mar 2016 15:12:13 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <C35AB581-9F37-409B-B837-F5572935AC8E@csperkins.org>
References: <55B4CAAF-50FB-4111-82EE-3B40B0D9C2F4@nostrum.com> <E25B484A-8F46-4A79-94CF-062AE66BD315@csperkins.org> <56ACF11C-4B54-48B4-94D9-C14008358E1B@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3112)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/CqvUoBTU3-wrjkWcx_TvSH4hT_I>
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: Wed, 16 Mar 2016 15:12:37 -0000

Hi,

Replies inline.

> On 7 Mar 2016, at 22:51, Ben Campbell <ben@nostrum.com> wrote:
> 
> 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...".

The SHOULD NOT is intended to apply to the device implementing the circuit breaker, not the peer that doesn’t implement RTCP. That is, it’s saying you shouldn’t disable the RTP circuit breaker unless you have some other way of getting congestion feedback. It’s not saying that non-RTCP devices shouldn’t be on the network. Would it help to change it to “The RTP circuit breaker SHOULD NOT be disabled on networks that might be subject to congestion, unless…”?

> 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.

Implementations that don’t implement RTCP _can’t_ implement this draft: this is an RTCP extension.

>>> -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..."?)

I’d expect an implementation will be able to infer this, but it’s an under-specified and likely poorly implemented part of RTCP. 

>>> 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.

Yes, with the caveat that if different DSCP values are being used for different flows, then it has to restrict the group to flows with the same DSCP.

> [...]
> 
>> 
>>> -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?

Sure, can do.

>> 
>>> - 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.

Fine.

> 
> 
>> 
>>> 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.

Okay.


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