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

From: Colin Perkins <[email-masked]>
Date: Wed, 4 Apr 2012 08:36:03 +0100

Mark,

So far, we haven't really considered RTP/AVPF rapid feedback (Section 5 of the draft is essentially a placeholder, and the mechanisms in Section 4 are specifically for baseline RTCP). As you've noticed, it changes the dynamics significantly, and we need to think carefully on how the various rapid feedback modes interact with the circuit breaker conditions before we define anything.

Colin

On 4 Apr 2012, at 02:55, Mark Handley wrote:
> Colin, Varun,
> 
> Can you clarify how the circuit breaker mechanism would work with RFC
> 4585 extended feedback.  To make things concrete, I'm thinking about
> the following scenario:
> 
> - Sender is sending 2Mb/s video into a 4Mb/s DSL line.  RTT is 100ms.
> - Receiver is allowed to send up to 2.5% of this as RTCP feedback in
> ACK mode, so that's 6.5 packets per RTT if I got the maths right.
> - A TCP flow slowstarts, doubles the window for the last time and
> collides with the RTP flow in the wonderful way slowstart sometimes
> does.  If you're unlucky, you'll get 33% packet loss for one full RTT
> before TCP backs off.
> - The RTCP receiver sends 6 successive RTCP reports over one RTT
> indicating 33% loss.  If doesn't really matter if ACKs or NACKs are
> sent in this scenario.
> 
> The calculated TCP rate would be ~18Kb/s for those parameters, so the
> circuit breaker would kick in if I understood the draft correctly
> because that's more than two reporting intervals with excessively high
> loss.
> 
> This is the main reason for loss event rate in the TFRC specification
> - you avoid responding to such transients too strongly.
> 
> Cheers,
> Mark
> 
> 
> 
> On 5 March 2012 23:32, Colin Perkins <[email-masked]> wrote:
>> Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
>> 
>> Colin
>> 
>> 
>> 
>> Begin forwarded message:
>>> From: [email-masked]
>>> Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>> Date: 5 March 2012 20:17:59 GMT
>>> To: [email-masked]
>>> Reply-To: [email-masked]
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> 
>>>       Title           : RTP Congestion Control: Circuit Breakers for Unicast Sessions
>>>       Author(s)       : Colin Perkins
>>>                          Varun Singh
>>>       Filename        : draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>>       Pages           : 14
>>>       Date            : 2012-03-05
>>> 
>>>   The Real-time Transport Protocol (RTP) is widely used for telephony,
>>>   video conferencing, and telepresence applications.  These
>>>   applications are often used over best-effort UDP/IP networks.  If
>>>   congestion control is not implemented then network congestion will
>>>   deteriorate the user's multimedia experience.  This document does not
>>>   propose a congestion control algorithm.  Instead, it specifies a
>>>   minimal set of "circuit-breakers".  Circuit-breakers are conditions
>>>   under which an RTP flow should cease to transmit media to protect the
>>>   network from excessive congestion.  It is expected that all RTP
>>>   applications running on best-effort networks will be able to run
>>>   without triggering these circuit breakers in normal operation.
>>> 
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>> 
>> --
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Varun Singh <[email-masked]>
Date: Wed, 4 Apr 2012 16:08:15 +0300

Hi Mark,

As Colin pointed out, currently the circuit breakers are defined for
baseline RTCP. Just to clarify: the circuit breaker should give
sufficient time for a rate-control to operate in. For example, the
REMB message should be sent (as a non-compound RTCP) much before the
circuit breaker kicks in and at the same time the circuit breaker
should not make the receiver send the REMB message prematurely.

Varun

On Wed, Apr 4, 2012 at 10:36, Colin Perkins <[email-masked]> wrote:
> Rtp-congestion mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Mark Handley <[email-masked]>
Date: Wed, 4 Apr 2012 02:55:32 +0100

Colin, Varun,

Cheers,
Mark