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
