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

[Simon Perreault <[e-mail]>]

Le 2015-05-17 09:36, Colin Perkins a écrit :
>> 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.

I think that would be helpful!

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

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.

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

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

Simon