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

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Feb 2013 00:18:40 +0000

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/

---

From: Kevin Gross <[email-masked]>
Date: Mon, 18 Feb 2013 09:48:41 -0700

Because the circuit breaker is conservative, my assessment is that things
are clearly badly busted when the breaker trips. In this case, over the
duration of 3 RRs, not a single RTP packet has been delivered. If this is
due to moderate congestion or flow control, you'd expect at least a few of
the packets to get through. If none are getting through, there is either a
connectivity problem or possibly congestive collapse. In neither case is
reducing rate by a factor of 10 a useful response. Have I missed something?
What sort of failure scenario are you thinking of where the reduced rate
would be successful?

I am also concerned about scope. Circuit breakers are a safety net and
should not interfere with congestion management techniques as they are
developed. Circuit breakers should conservatively detect faults and trip.
They should not half-trip or automatically reset themselves.

On Tue, Feb 12, 2013 at 5:18 PM, Colin Perkins <[email-masked]> wrote:

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

---

From: Colin Perkins <[email-masked]>
Date: Sat, 23 Feb 2013 18:57:35 +0000

Kevin,

If the problem is congestion collapse, then a factor of ten reduction in sending rate may well help. However, I see your point, and will change the draft to only suggest ceasing transmission for this circuit breaker.

Colin

On 18 Feb 2013, at 16:48, Kevin Gross wrote:
> Because the circuit breaker is conservative, my assessment is that things are clearly badly busted when the breaker trips. In this case, over the duration of 3 RRs, not a single RTP packet has been delivered. If this is due to moderate congestion or flow control, you'd expect at least a few of the packets to get through. If none are getting through, there is either a connectivity problem or possibly congestive collapse. In neither case is reducing rate by a factor of 10 a useful response. Have I missed something? What sort of failure scenario are you thinking of where the reduced rate would be successful?
> 
> I am also concerned about scope. Circuit breakers are a safety net and should not interfere with congestion management techniques as they are developed. Circuit breakers should conservatively detect faults and trip. They should not half-trip or automatically reset themselves.
> 

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