Re: [rtcweb] Review of draft-ietf-rtcweb-rtp-usage

[Colin Perkins <[e-mail]>]

On 8 May 2014, at 19:17, Bernard Aboba <[e-mail]> wrote:
>> On May 8, 2014, at 9:47 AM, Emil Ivov <[e-mail]> wrote:
>>> 
>>> The circuit breaker is a mechanism of last resort. If we’ve designed it correctly, it will only stop sessions that are otherwise unusable.
> 
> [BA] Unusable at a given moment could change to usable later, either as a result of congestion control support and/or changing conditions. So it is one thing to stop sending for some period and indicate to the user that difficulties are being experienced then try again after backing down the send Bw, and another to stop and require a redial. 

The circuit breaker draft explicitly allows for this back-off and resume behaviour. From section 4.3 of draft-ietf-avtcore-rtp-circuit-breakers-05:

   Systems that usually
   send at a high data rate, but that can reduce their data rate
   significantly (i.e., by at least a factor of ten), MAY first reduce
   their sending rate to this lower value to see if this resolves the
   congestion, but MUST then cease transmission if the problem does not
   resolve itself within a further two RTCP reporting intervals (see
   Section 4.5).  An example of this might be a video conferencing
   system that backs off to sending audio only, before completely
   dropping the call.  If such a reduction in sending rate resolves the
   congestion problem, the sender MAY gradually increase the rate at
   which it sends data after a reasonable amount of time has passed,
   provided it takes care not to cause the problem to recur
   ("reasonable" is intentionally not defined here).

If there is a congestion control algorithm implemented in addition, then this ought to back off long before the circuit breaker would trigger anyway, so the problem won’t occur.

>> This is another part that bothers me with circuit breakers. If there's a reasonable chance that a "redial" would succeed then why did we break the session? If not then why are we encouraging it?
> 
> [BA] As specified, circuit breakers is vulnerable to routing transients. Other transports such as TCP are explicitly designed to survive this, but circuit breakers will not.  So we need to ask ourselves why TCP never needed (or considered) such a mechanism.

I suggest that the user will almost certainly have hang-up the call in frustration as a result of the drop-out before the circuit breaker fires. If people think the timeouts in the circuit breaker draft are too short, or the packet loss thresholds too tight, then please comment on the circuit breaker draft (in AVTCORE) and we’ll work to improve it. So far, we haven’t had any real push-back against the approach taken in that draft. 

I do think a circuit breaker is REQUIRED for WebRTC, however, especially as RMCAT is not making rapid progress with congestion control.

Colin


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