Colin, Thanks for sharing the information. Actually, while I was offline, I modified my algorithm because I observed that during one GoP interval (typically 400ms), I received multiple TFRC ACKs causing the new max-rate og TFRC to be recalculated. My first version used the newest max-rate before starting a new GoP (for the rate control algorithms leaky bucket). This last version was the most starved one. In my second version I calculate the plain average over all max-rates given by TFRC during the last GoP. This had a very stabilizing effect, indeed, since the rate given to the rate controller is more representative to the actually throughput the last GoP. The plan is to release the stable code as ns-2 addon later on. Arne On Mon, March 13, 2006 4:46 pm, Colin Perkins wrote: > Arne, > > On 13 Mar 2006, at 14:34, Arne Lie wrote: >> I am performing experiments with VBR rate controlled video over >> TFRC (in >> ns-2.28). [I have also noticed the VoIP initiative in DCCP, to cope >> with >> silent periods etc., so I believe that my findings could be >> "compliant" to >> the motivation behind that initiative.] >> >> My results with VBR video (using I- and P-frames) shows that it is >> very >> hard for the application to grab available capacity, if the TFRC send >> queue is kept short to minimize overall latency. When this queue is >> short, >> it is often drained completely, while transmitting the smaller P- >> frames. >> Thus, the actual sending rate is lower than the allowed sending >> rate, and >> the TFRC is "trapped" in the slowstart phase, often causing a step- >> down of >> actual max rate to the previous measured sending rate. It can actually >> force "oscillations" in the algorithm (measurement period is >> smaller than >> the Group of Pictures (GOP), thus some measurements contain only P- >> frames, >> while others contain also the larger I-frame). If the sending queue is >> allowed to become larger, the TFRC rate is somewhat smoother, but >> still >> the results are not satisfactory. >> >> Can someone reply and answer if my findings are just "old news", >> and only >> reflects defects that the new "VoIP" flavoured TFRC will "repair"? > > We see somewhat similar behaviour, sending M-JPEG over a real-world > TFRC implementation. We haven't tried TFRC-SP (a.k.a. TFRC-VoIP), but > I doubt it would make a difference with our application, since we > send large packets. > > Colin >
