Hi Harald, <div><br></div><div>   I think there's some misunderstanding here.</div><div><br></div><div>   1. 
ledbat is using qeueing delay, not the base rtt, the queuing delay is relative_owd - relative_base_owd, and clock skew is removed.</div><div><br></div><div>   2. I mentioned ledbat here for i think there's simpler way to get the queuing delay as a hint for congestion, and can be used for give estimation of bandwidth.</div>
<div><br></div><div><br></div><div>Thanks</div><div>Jeromy<br><br><div class="gmail_quote">2012/4/6 Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 04/06/2012 01:45 AM, Matt Mathis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is one especially useful design point to extract here.....<br>
<br>
I believe that by default ledbat has a 50mS set point.  That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS.<br>
</blockquote></div>
That is - 50 ms more than the baseline (lowest observed) RTT?<br>
50 ms absolute would make no sense, since intercontinental conferencing has a longer baseline RTT.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point?<br>
</blockquote></div>
I generally don't like set-points, since they tend to make behaviour converge on the set-point. Sliding scales like the Kalmann filter of Stefan's proposal make more sense to me.<br>
<br>
That said, 50 ms seems a little on the high side, given that our total RTT budget is being attacked from all sorts of directions, but not order-of-magnitude wrong.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</div></div></blockquote></div><br></div>