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.
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.