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

From: Simon Perreault <[email-masked]>
Date: Fri, 08 May 2015 12:47:15 -0400

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!

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

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?

---

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

---

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?

---

From: Colin Perkins <[email-masked]>
Date: Sun, 17 May 2015 14:36:37 +0100

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 <[email-masked]> wrote:
> 
> Authors, WG,
> 

Thank you!

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

> would it be OK to arm circuit breakers upon reception of a first RTCP

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?

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

> would help to be explicit about this.

Yes. Will do.

> "more than one RTP packet per RTT" condition, so my comments also apply

Sure; same answer. Will clarify there too. 

> rely on the receiver hanging up, instead of guessing what might be

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.

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 May 2015 17:53:06 -0400

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

I think that would be helpful!

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

Good point. When RTCP is signalled then one can arm circuit breakers
immediately. Otherwise one would arm them on receipt of a first RTCP packet.

I think it would be useful to non-normatively describe such a heuristic.
I can provide text if you'd like.

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

Right, ok, but I still wouldn't know how to implement that...

Simon