Dear all, 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"? Or, is it possible to e.g. tell TFRC to do more seldom rate measurements so that to avoid oscillations due to the GOP periodicity? Best regards Arne Lie NTNU, Norway
