[R-C] [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web

[Stefan Holmer]

Hi,

I don't think we have anything to share at the moment, but we might be able
to produce some numbers if we knew what you are interested in.

/Stefan

On Tue, Dec 13, 2011 at 11:36 PM, Harald Alvestrand <harald at alvestrand.no>wrote:

> **
> [limiting to mailing list and original posters]
>
> Henrik, Stefan, do we have measurements we can share?
>
>
>
> On 12/05/2011 09:21 AM, Saverio Mascolo wrote:
>
> hi all,
>
>  the model could be weak....however before going into "theoretical
> questions" can we look at  measurements?
>
>
>  thanks
> saverio
>
>  On Mon, Nov 7, 2011 at 2:58 AM, Wesley Eddy <wes at mti-systems.com> wrote:
>
>> On 11/1/2011 10:34 AM, Lars Eggert wrote:
>>
>>> This may be of interest to the RG:
>>> http://wiki.tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01
>>>
>>>
>>
>>  Here are my comments on this (also copied to the authors and the
>> mailing list for RTCWEB congestion control):
>>
>> (1)
>> I think the model tries to correct for some effects later, but this
>> part only makes sense if all frames are the same size, and none of
>> the timestamps are subject to jitter being introduced by OS scheduling,
>> MAC layer (e.g. wireless) issues, etc:
>> """
>>   We define the (relative) inter-arrival time, d(i) as
>>
>>     d(i) = t(i)-t(i-1)-(T(i)-T(i-1))
>> """
>>
>> (2)
>>
>> This part doesn't quite make sense to me, but I think it's just in
>> the wording and not in the math:
>> """
>>   Since the time ts to send a frame of size L over a path with a
>>   capacity of C is
>>
>>     ts = L/C
>>
>>
>>   we can model the inter-arrival time as
>>
>>              L(i)-L(i-1)
>>     d(i) = -------------- + w(i) = dL(i)/C+w(i)
>>                  C
>> """
>> That's not a model of the inter-arrival time, it's a model of the
>> difference between the delta timestamps and delta reception times
>> based on difference in packet length.
>>
>>
>> (3)
>> In the definition of w(i), do you also intend to account for other
>> sources of delays in the end systems' software?  Why do we think that
>> white noise is the right model?  This seems like a big assumption,
>> unless there's actually data that shows it holds under a very wide
>> range of settings.
>>
>> (4)
>> It should probably be understood clearly that the i values are sample
>> numbers, but that the generation of samples comes from the behavior of
>> the plant, and they aren't taken at the filter/controller regularly.
>> This seems to be quite different than when the document says:
>> """
>>   In this document we make the assumption that the rate control
>>   subsystem is executed periodically and that this period is constant.
>> """
>>
>> (5)
>> The algorithm at the receiver side is clueless about packet losses,
>> and seems like it would see them only when the loss period ends (when
>> a packet survives) and then would see them as really long inter-arrival
>> times rather than losses?  (or did I miss something really important?)
>>
>>
>> (6)
>> The rules about 2% and 10% in the sender-side algorithm seem ... odd.
>> Unless the report interval is sufficiently long in relation to the frame
>> rate, the percentages may not work well.  These parameters have to be
>> balanced, or the algorithm will be fragile.
>>
>> (7)
>> Shouldn't the sender estimate of available bandwidth be able to go lower
>> than the TFRC equation output if the delay has been increasing (though
>> packets are not yet being lost)?
>>
>> (8)
>> Startup is a big topic that isn't yet addressed.
>>
>>
>>
>>
>> --
>> Wes Eddy
>> MTI Systems
>>
>> _______________________________________________
>> Iccrg mailing list
>> Iccrg at cs.ucl.ac.uk
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>
>
>
>  --
> Prof. Saverio Mascolo
> Dipartimento di Elettrotecnica ed Elettronica
> Politecnico di Bari
> Via Orabona 4, 70125 Bari Italy
> Tel. +39 080 5963621
> Fax. +39 080 5963410
> email:mascolo at poliba.it
>
> http://c3lab.poliba.it
>
>
> =================================
>  This message may contain confidential and/or legally privileged
> information.
>   If you are not the intended recipient of the message, please destroy it.
>  Any unauthorized dissemination, distribution, or copying of the material
> in
>  this message, and any attachments to the message, is strictly forbidden.
>
>
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20111214/b3359489/attachment.html>