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

[Ingemar Johansson S]

Hi

And very sorry for the delay. 
Thanks for the link to the report, it should give some answers.

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.

Regards
/Ingemar 

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:S.Choi at cs.ucl.ac.uk] 
> Sent: den 13 september 2010 14:19
> 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,
> 
> > 
> > I have a question regarding TFRC-SP (RFC4828). It states a maximum 
> > packet rate or 100 packets/s. What was the rationale behind this 
> > restriction ?. Suppose that a 2Mbps video codec use TFRC-SP (mainly 
> > because TFRC Inter packet Interval may be difficult to 
> implement given 
> > various OS concerns). This would give a packet rate of ~170packets/s
> > 
> > My question... How does this affect the stability of TFRC-SP ?
> > 
> 
> 
> That's right - the OS's clock granularity can limit the 
> calculated TFRC rate. I would imagine that the issues with 
> the OS's clock granularity is something that you cannot get 
> away from when using a rate-based protocol.
> 
> 
> As you know, TFRC-SP, however, is mainly intended to be used 
> for a VoIP type of applications (e.g., with smaller packets). 
> In general, video packets are much bigger than the usual VoIP 
> packets, so it might be inappropriate to use it without 
> careful consideration - TFRC-SP used with 1460 bytes packet 
> size would break fairness when competing with standard TCP 
> flows (see 
> <http://icapeople.epfl.ch/widmer/tfmcc/vp-tfmcc.html> for the 
> detailed reasoning behind this). It basically says the 
> smaller the packet size, the more the flow will receive 
> bandwidth sharing (if not modifying the loss event 
> calculation method).
> 
> RFC4828 explained some of the reasoning there as well (see 
> RFC4828 Section 4.3).
> 
> 
> Cheers,
> Soo-Hyun
> 
>