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

[Randell Jesup]

On 10/28/2011 6:00 AM, Varun Singh wrote:
>>> 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.
>
> I agree with Harald on this.

I was trying to avoid defining 'fair' at all costs.  Hopefully no one 
will want to define "reasonable"...

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

Sure.

>>>         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"
>
> using data is a bit confusing because data else where in the text
> means data channel.
>
> "reporting of a recipient's estimate of available bandwidth for
> receiving the combined media and data streams"

Yes, thanks

> Just to confirm:
> the receiver calculates the rate per stream and then adds them up:
> CT_combined = R_audio  + R_video + R_data
> and the audio and video channels calculate the rate as described in
> the proposal.

Or it calculates a total rate directly - or it makes a wild-assed-guess. 
  :-)  We're not specifying how it gets these numbers here (in the 
normative wordings).  And if running them separately, one will 'notice' 
congestion before the others, always, so you need to think about how 
you'd merge individual reports - doing as you mention (with the straight 
algorithm in Harald's draft) would likely lead to not going far enough 
down until the other channels noticed the congestion, if they did.  If 
as I suggested you use the 'slope' of the incoming packet rate to 
estimate the amount under/over bandwidth, even with Harald's algorithm, 
you could apply that slope correction factor across all the estimates. 
Without it, you could apply a correction factor based on recent state 
changes in the individual readings; more complex than just adding them.

> The sender uses the receiver CT_combined and the current sending rate
> of each channel to re-allocate the distribution. Is the aim to try and
> get the distribution similar to what the receiver envisioned or is the
> sender free to do whatever?

I this case the sender has no idea what the receiver envisioned - but 
even if it did, I'd say it's free to do whatever.  If the receiver wants 
to control individual channels more (no guarantees), it should use 
individual TMMBR reports.

>>>
>>>         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.
>>>
>
> Is the data sent using the same congestion control mechanism?

We would like it to be included or at least interactive with the 
algorithm, but that's not currently required and we can't guarantee it 
will happen.  SCTP does allow for variant CC algorithms, so we certainly 
have the option if we can work it out.

>>>     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....
>
> I agree with the MAY as it is yet to be proven useful.
>
>>>
>>>         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.

Ok, but we'll need to resolve this issue later.  I'm fine with not 
mentioning optimizations here.

>>>     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.
>>>
>
> Will we propose an algorithm or lower or upper-bound for this? like:
> not quicker than once per RTT even if the 5% rule allows it. Or send
> an early report when loss, inter packet delay, etc exceeds a given
> threshold.

My inclination would be to not put any limit on it.  Even the RTT thing 
isn't necessarily a good idea; I may have a more accurate estimate 
shortly after sending a preliminary report.  I wouldn't (as a sender) 
increase my sending rate more than once per RTT (actually probably 
slower than that), but I might decrease it in less than an RTT - think 
satellite with 1s RTT...

>>>     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?
>
> MUST be enabled?

      6.  Data channels MUST be congestion-controlled 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.
>>
>> 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.
>
> The receiver doesn't know the end-to-end delay, the RTT is calculated
> at the sender. So is the sender making this decision or the receiver?

Almost by definition the sender.  The receiver is reporting data for the 
sender to use.  (You can consider the receiver part of the algorithm, of 
course.)

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

For any CC algorithm to work, it really *should* try.  It may not be 
able to comply, the algorithm may include some smoothing, and the sender 
may have additional information, so it's not MUST, but wouldn't MAY be 
too weak?

> Does the application know apriori how much data would be sent on the
> data channel? because it is likely that the sender would want to use
> all of the signaled bandwidth for audio and video. (Especially if the
> data channel is used for IM, which may be used sporadically).

It may or may not know ahead of time.  It controls how much data IS 
sent, however.

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




-- 
Randell Jesup
randell-ietf at jesup.org