Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-01.txt

[Colin Perkins <[e-mail]>]

Hi Kevin,

Thanks for these comments. I've incorporated most of them into the draft ready for the next version, which will be submitted before the deadline. Some comments inline.

On 5 Nov 2012, at 21:56, Kevin Gross wrote:
> Comments on this draft. Some I mentioned in the session today. Smaller ones I did not.
...
> Last bullet point on page 4 mentions that RTCP report interval is dependent on number of participants in the session. Number of participants in a unicast session is always 2 so this is not a contribution if multicast is our of scope.

Participants was misleading: what matters is the number of SSRC values, which can be greater than two in a unicast session if the participants send multiple media streams.

...
> p.7 The following text may need work:
> 
> "The remaining congestion signals are the packet loss fraction and the
>    cumulative number of packets lost.  These are robust indicators of
>    congestion in a network where packet loss is primarily due to queue
>    overflows, although less accurate in networks where losses can be
>    caused by non-congestive packet corruption.  TCP uses packet loss as
>    a congestion signal." 
> 
> TCP intentionally causes congestion to determine available link bandwidth. It is using packet loss to measure capacity. In the presence of TCP characterizing loss fraction as a roust indicator is probably an overstatement. The interaction probably deserves some some further investigation.

Agree. I expanded this text slightly, but more might need to be said.

> Section 4.1: Delete second paragraph. As disused in the session today, if things are messed up enough to trigger circuit breaker #1, reducing offered load is not likely a useful response. Section 4.3 contains a copy of this recommendation and is probably an appropriate recommendation for circuit breaker #3 described there.

If this were a congestion control algorithm, I'd probably agree that we should be more aggressive in stopping transmission here, but the circuit breaker is supposed to be conservative when it fires, to encompass all reasonable congestion control behaviours. As such, I think it is better that the draft allow the option of reducing offered load as a response here, rather than mandate ceasing transmission immediately.

> Section 4.2: As discussed in the session today, this section needs to be improved to discuss devices that don't implement RTCP. One obvious improvement is to condition the receiver behavior described at the bottom of page 9. A receiver should not trip this circuit breaker if it is receiving RTP packets from the sender.

None of these circuit breakers work if RTCP is not implemented. I'll clarify at the start of section 4.

> Section 4.3: Simulation is required to gain confidence that there are no false-trigger conditions for this circuit breaker. Test in the presence of competing TCP flows. Test different RTCP RR reporting delay and packet loss scenarios. Solicit more ideas from others.

In progress.

Cheers,
Colin


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