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

[Harald Alvestrand]

[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 
> <mailto: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 <mailto: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 <mailto:email%3Amascolo 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20111213/43bf4ec7/attachment.html>