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.