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

[Harald Alvestrand]

Rest of comments look fine, I think....

On 10/28/2011 06:18 AM, Randell Jesup wrote:
>
>>>>     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?
I was thinking that in some applications over some codecs, it may simply 
drop packets, layers or channels, without adjusting any parameters. 
Suggest that we insert ", for instance" in front of "by adjusting" - so 
that it becomes "the sender shall attempt to comply with the overall 
bandwidth requirements, for instance by adjusting parameters it can 
control".

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

This should be OK for the first cut - long term, we have to discuss what 
"comply" means ... whether a leaky bucket algorithm (which would permit 
some over-bandwidth burstiness) is an appropriate model, and if so, how 
deep the bucket should be, or whether that's a tunable parameter that 
can be freely set by the implementation within some boundaries, or...... 
for now, let's get a simple statement that is understandable to the main 
list.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20111028/3f5607ae/attachment-0001.html>