[Iccrg] Re: TFRC-SP and maximum packet rate

[Soo-Hyun Choi]

Hi,

> 
> An issue with modern video codecs is that they produce frames with
> larger differences in frame size. For instance I-frames may be so big
> that they need to be split up in several packets (for PMTU reasons)
> while B- and P-frames are considerably smaller. The effect of this is
> that even though the framerate of the video is 30Hz, the packet rate
> may be considerably higher when I-frames are transmitted. But I guess
> the only way to determine how TFRC-SP works in these cases is to try
> it out.

You are right - the packet size will significantly vary depending on the
types of the frame (I, B, or, P) and video content as well. As I said
earlier, using TFRC-SP for video streams without a modification may
break the (proportional) flow-level fairness when competing with the
standard TCP flows.

There is another similar work that studied TFRC performance with the
variable packet sizes -
<http://www.icsi.berkeley.edu/ftp/pub/techreports/2000/tr-00-008.pdf>
This work also mentioned the fairness issues and solve the problem by
estimating the mean packet size (assuming PMTU is known a priori).

However, it is unclear to me as to how much the approximated packet size
is meaningful to the calculated send rate (because, the frame sizes are
so varying as we know).

I have an on-going work to solve these problems by re-introducing the
TCP-like Ack-clocking mechanism while retaining the smoothness property
in the send rate (of course, for the interactive video streaming
applications). I should be able to publish the results somewhere in the
next month or so. If you are interested, I can send you the draft copy
sometimes early next month.


Cheers,
Soo-Hyun