[R-C] Proposal comments (Re: RTCWEB Congestion Control Standardization)

[Harald Alvestrand]

Commenting on Randell's proposal, not on the alternatives, so changing 
subject....

On 10/26/2011 01:57 PM, Randell Jesup wrote:
>
> 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.
I'd use "reasonably fairly" to reduce (slightly) the chances of getting 
lost in the definition of "fair" and the number of angels who can dance 
on the head of a pin.
>
>     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
Suggest moving the part before the comma to an intro paragraph. It's an 
overall goal.
>         name here] shall be defined to allow reporting of total
>         predicted bandwidth for receiving data, as opposed to
"reporting of a recipient's estimate of available bandwidth for 
receiving data"
>         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.
8 bytes in the proposal I'm editing in another window....
>
>         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.
would make more sense to me to only include it if it varied more than N 
microseconds from (the time specified by the RTP timestamp for the frame 
+ a constant delay). Suggest omitting this for what you propose to the 
larger group.
>
>     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.
What does "work" mean if there is no data?
>
>     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.
Not sure I understand this. If I understand it, suggest to rewrite as

    7. The congestion control algorithm SHOULD attempt to minimize the 
media-stream
        end-to-end delays between the participants, by controlling 
bandwidth appropriately.
>
>     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.
Suggest "shall" -> "may".
>
> 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.
>
There may be adjustments that need communicating with the other end too 
(renegotiation). It's reasonable to assume that these are only performed 
when requested through the JS layer.