Re: [MMUSIC] Congestion controll

[Cullen Jennings <[e-mail]>]

I think everyone is on board with the fact that RTP represents what you would call an envelope from a congestion point of view. Exactly what can be changed inside that envelope and how might be a question and but that seems a very different one than the plan A / plan B discussion. Regardless of what happens with envelopes and congestion control, both plan A and B don't change and work with that answer. 

more inline … 


On Jun 7, 2013, at 2:31 AM, Bernard Aboba <[e-mail]> wrote:

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

Sure, I agree. I would say it as when we need to reduce the sending rate rapidly due to significant congestion, relying on round trips of signaling to do this may be too slow. 

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

Of course. Agree

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

This is the part I strongly disagree with. I think both plan A and B allow any type of control that is acceptable in RTP / SDP for this including the use of RTCP. I can't see how plan A / B have anything to do with this. 


>   If an O/A exchange is required for a sender to drop a stream, rapid adaptation (including congestion control) is hampered. 

No O/A is request to stop sending RTP packets on a given stream. Plan A / B have nothing to do with that one way or another.

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