Re: [rtcweb] #19: Section 7.2: Congestion Control Extensions

[Colin Perkins <[e-mail]>]

On 20 Apr 2013, at 02:48, rtcweb issue tracker wrote:
> #19: Section 7.2: Congestion Control Extensions
> 
> 7.2.  RTCP Extensions for Congestion Control
> 
>    As described in Section 5.1.6, the Temporary Maximum Media Stream Bit
>    Rate (TMMBR) request is supported by WebRTC senders.  This request
>    can be used by a media receiver to impose limitations on the media
>    sender based on the receiver's determined bit-rate limitations, to
>    provide a limited means of congestion control.
> 
>    (tbd: What other RTP/RTCP extensions are needed?)
> 
>    With proprietary congestion control algorithms issues can arise when
>    different algorithms and implementations interact in a communication
>    session.  If the different implementations have made different
>    choices in regards to the type of adaptation, for example one sender
>    based, and one receiver based, then one could end up in situation
>    where one direction is dual controlled, when the other direction is
>    not controlled.
> 
>    (tbd: How to ensure that both paths and sender and receiver based
>    solutions can interact)
> 
> [BA] Some nasty unresolved issues here. In particular, I am concerned
> about potential gaps in worldview between sender-side and receiver-side
> congestion control implementations.  Is our goal here to guarantee that a sender-side implementation can interoperate with a receiver-side
> implementation? Or that a sender-side implementation has the information it needs?


I don't think either is the goal. As we don't have a congestion control solution from RMCAT yet, I believe the goal for this draft should be to allow signalling of known boundary conditions on the acceptable rate, and to ensure the necessary RTP/RTCP features to implement congestion control are available in implementations.

TMMBR requests fall into the former category. They're not designed, or suitable, for effective congestion control. Rather, they allow signalling of known constraints within which congestion control can operate. Section 7.1 of the draft, immediately before the text you quoted, says this better. I will therefore remove the paragraph about TMMBR you quoted from the draft.

The draft says "(tbd: What other RTP/RTCP extensions are needed?)". I think this answer here is none: we have RTP/AVPF feedback, RTP header extensions, non-compound packets, and the ability to tune the reporting interval. These are enough to convey congestion reports in a reasonably low-overhead manner. Anything else will depend on the algorithm, and so belongs in the draft defining the standard RMCAT congestion control algorithm.

The text quoted about proprietary congestion control algorithms, and interoperability between sender- and receiver-driven algorithms is a real issue, but not one that I think this draft can resolve. I'll move the quoted text into Section 7.4, where it fits better, and try to clarify that the problem is one that should be addressed by agreement on the congestion control algorithm at the signalling layer, and an effective standard from RMCAT.

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