[R-C] RTCWEB Congestion control Standardization (repost)

[Randell Jesup]

Harald pointed out that my first posting of this was officially a reply 
to an earlier message that some may have missed, so I'm reposting as a 
top-level item.  -- Randell

On 10/10/2011 5:22 AM, Magnus Westerlund wrote:
> So what are our alternative here?
>
> 1) Pick TFRC for now while developing something better? Possibly ensure
> that the RTP mapping gets published in a reasonable time frame.
>
> 2) Try to write clear requirements on the implementation, but no
> specification and hopes that goes through?
 >
> 3) Develop something and delay the publication of any part that needs
> this until it is done?
>
> 4) ?
>
> Regarding 3), I don't see how that is going to complete in less than 2
> more likely 3 years. Spin up a TSV WG, develop a solution. Simulate and
> discuss corner cases for a while before getting good enough out.

I vote for 2, and provide a sample implementation and let people 
innovate.  I would also support trying to standardize the sample 
implementation under 3 in parallel, with the understanding it will take
A Long Time.

Here's a set of proposed stab at requirements for rtcweb implementations:

As part of rtcweb, congestion control must be addressed:

     1.  All WebRTC media and data streams MUST be
         congestion-controlled.

     2.  The congestion algorithms used MUST cause WebRTC streams
         to act fairly with TCP and other congestion-controlled
         flows, such as DCCP and TFRC, and other WebRTC flows.  Note
         that WebRTC involves multiple data flows which "normally"
         would be separately congestion-controlled.

     3.  In order to support better overall user experiences and to
         allow applications to have better interaction with
         congestion control, a new AVPF feedback message [ insert
         name here] shall be defined to allow reporting of total
         predicted bandwidth for receiving data, as opposed to
         TMMBR, which requests a sending rate for a single SSRC
         flow.  [ This is roughly equivalent to b=CT:xxx ]

         We may want to give the estimation algorithm the option to
         not include or exclude the data-channel bandwidth, but it
         SHOULD include that.

     4.  In order to facilitate better operation of
         bandwidth-estimation algorithms on the receiving side, the
         sending side MAY include a transmit-time RTP header
         extension (TBD) to some or all media streams. Note that
         this will add about 12 bytes to each RTP packet.

         An optimization may be to only include these timestamps if
         they deviate by more than [ some amount TBD from the
         running average and from the number of bytes preceding it
         with the same timestamp ].  This is based on the fact that
         for many devices, the sample->send interval is fairly
         consistent at the levels of accuracy needed here, and so
         significant bandwidth savings can be made.

     5.  The receiver SHOULD attempt to minimize the number of
         bandwidth reports when there is little or no change, while
         reporting quickly when there is a significant change.

     6.  Congestion control MUST work even if there are no media
         channels, or if the media channels are inactive in one or
         both directions.

     7.  The congestion control algorithm SHOULD attempt to keep the
         total bandwidth controlled so as to minimize the media-
         stream end-to-end delays between the participants.

     8.  When receiving a [ insert new AVPF message here ], the
         sender shall attempt to comply with the overall bandwidth
         requirements by adjusting parameters it can control, such
         as codec bitrates and modes, and how much data is sent on
         the data channels.

Not part of our IETF requirements, at the JS level bandwidth changes 
should be reported to the application along so that it has the option to 
make changes that we can't make automatically, such as removing or 
adding a stream, or controlling the parameters of a stream (frame rate, 
etc).  Note that if the application doesn't do anything, the automatic 
adaptation will still occur.

-- 
Randell Jesup
randell-ietf at jesup.org