Hi Harald, I think there's some misunderstanding here. 1. ledbat is using qeueing delay, not the base rtt, the queuing delay is relative_owd - relative_base_owd, and clock skew is removed. 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. Thanks Jeromy 2012/4/6 Harald Alvestrand <harald@alvestrand.no>
On 04/06/2012 01:45 AM, Matt Mathis wrote:
There is one especially useful design point to extract here.....
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.
That is - 50 ms more than the baseline (lowest observed) RTT? 50 ms absolute would make no sense, since intercontinental conferencing has a longer baseline RTT.
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point?
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.
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.
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>