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