Re: [MMUSIC] Congestion controll

[Bernard Aboba <[e-mail]>]

In a highly congested environment, signaling will also be likely to be disrupted.   Therefore if signaling is necessary for a sender to reduce the sending rate (e.g. for example, in order to reduce resolution or framerate), then that rate reduction would itself be disrupted by congestion, preventing the sender from reducing rate, and thereby potentially resulting in congestive collapse. 
 
The solution to this, which has been widely implemented, is to enable rate reductions (such as removal of simulcast or layered streams) without a dependency on signaling.  This is possible because the initial O/A exchange focuses on negotiating the *envelope* of acceptable resolutions, frame rates, streams, etc. rather than attempting to control what is actually being sent in realtime.  As a result, the sender can reduce rate very quickly by dropping streams, with no signaling dependency.
 
It would appear to me that both Plan A and Plan B use signaling not just to control the envelope of acceptable configurations, but to determine what is actually being sent at a given moment.   If an O/A exchange is required for a sender to drop a stream, rapid adaptation (including congestion control) is hampered. 
 
 

 
> Subject: Congestion controll 
> From: [e-mail]
> Date: Thu, 6 Jun 2013 12:46:20 +0700
> CC: [e-mail]; [e-mail]; [e-mail]
> To: [e-mail]
> 
> 
> On Jun 5, 2013, at 9:41 AM, Bernard Aboba <[e-mail]> wrote:
> 
> > As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed and will break congestion control
> 
> Bernard - that's a pretty strong statement. Uh, you want to explain how either plan A or B break congestion control?
> 
>