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

[Colin Perkins <[e-mail]>]

Simon,

Thank you for your comments, and apologies for the slow response. I've made some responses inline. 


> On 8 May 2015, at 17:47, Simon Perreault <[e-mail]> wrote:
> 
> 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!

Thank you!

> Thanks,
> Simon
> 
> ---
> 
> 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)?

If you want to interwork with those implementations, then you have no choice but to operate without a circuit breaker. I'd encourage you to use at least some form of consent check, to indicate that the remote end system still wants to receive your traffic, in such cases. I can add some words about this to the draft.

> 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
> packet?

I'm not sure that's something I'd want to standardise, but it seems a reasonable practical solution. I'd have thought RTCP was signalled most times, anyway?

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

The "at least one per RTT" bound is intended to be an approximate, long-term, average. Like much in the draft, it doesn't need to be too precise. I'm open to suggestions how best to phrase this in the text, but will try to add something. 

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

Yes. Will do.

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

Sure; same answer. Will clarify there too. 

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

In both cases, you should terminate the call without waiting for the user to hang up, if the loss or delay is such that the media will be unusable. This circuit breaker is intentionally vague, because different applications have different thresholds, but should be conservative, so it only terminates calls that are unambiguously unusable.

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

To protect the network, and avoid disrupting other applications, in case the user at the receiver has wandered off, and doesn't hang up when the call goes bad. Like most of the circuit breakers, I expect this will rarely be triggered because in the usual case – as you suggest – the users will have given up before the quality gets so bad as to trigger the circuit breaker. The circuit breakers are safety measures needed for the unusual cases.

Colin




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