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

[Simon Perreault <[e-mail]>]

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?