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

[Ingemar Johansson S]

Hi

Sorry about the delay. I have read the report below and it answers a lot of questions. My take is that even though TFRC may sometimes fail to be 100% fair against TCP it is anyway a lot better than nothing. I am very interested in your work so if you can send me a draft copy of your work I'd be more than happy.
>From my (wireless) perspective I still have some concerns as regards to how fast TFRC can react to the higher dynamics of for instance 3GPP access like LTE or HSDPA/EUL. I can imagine that one may need an additional emergency break to cope with this but I have no real work done to prove my point.

Some additional info:
My interest in TFRC is given by the initiative from Google et al to bring real time communication to the web platform (see http://www.alvestrand.no/mailman/listinfo/rtc-web )
My main interest in this area is congetsion control, a feature that I believe is very important as the real time media will in this case share the same bottlenecks as TCP. 

/Ingemar 

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:S.Choi at cs.ucl.ac.uk] 
> Sent: den 21 september 2010 13:59
> To: Ingemar Johansson S
> Cc: iccrg; tsvwg at ietf.org; kohler at cs.ucla.edu; floyd at icir.org
> Subject: Re: TFRC-SP and maximum packet rate
> 
> 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
> 
> 
> 
> 
>