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

[Varun Singh]

Hi,

Comments inline, apologies for the delay in response.

On Fri, Oct 28, 2011 at 16:18, Randell Jesup <randell-ietf at jesup.org> wrote:
> On 10/28/2011 6:00 AM, Varun Singh wrote:
>
>> 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.
>

So is using individual TMMBR reports acceptable? if it is possible
then the above text should reflect that. If not then the above text is
okay.

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

Alright.

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

I agree that to update the preliminary report, the endpoint will have
to send it less than 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.
>

Ok.

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

Probably, adding "sending-side" before congestion control would clarify it.

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

Okay.


-- 
http://www.netlab.tkk.fi/~varun/