Hi,<div><br></div><div>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.</div><div><br></div><div>/Stefan<br><br><div class="gmail_quote">
On Tue, Dec 13, 2011 at 11:36 PM, Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div bgcolor="#ffffff" text="#000000">
[limiting to mailing list and original posters]<br>
<br>
Henrik, Stefan, do we have measurements we can share?<div><div class="h5"><br>
<br>
<br>
On 12/05/2011 09:21 AM, Saverio Mascolo wrote:
<blockquote type="cite">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" target="_blank">wes@mti-systems.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>On 11/1/2011 10:34 AM, Lars Eggert wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);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/html/draft-alvestrand-rtcweb-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>
_______________________________________________<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/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. <a href="tel:%2B39%20080%205963621" value="+390805963621" target="_blank">+39 080 5963621</a><br>
Fax. <a href="tel:%2B39%20080%205963410" value="+390805963410" target="_blank">+39 080 5963410</a><br>
<a href="mailto:email%3Amascolo@poliba.it" target="_blank">email:mascolo@poliba.it</a><br>
<br>
<a href="http://c3lab.poliba.it" target="_blank">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>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
<br></blockquote></div><br></div>