Subject: TFRC-SP and maximum packet rate

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 13 Sep 2010 08:19:17 +0200

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 ?

Regards
Ingemar

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: Soo-Hyun Choi <[email-masked]>
Date: Mon, 13 Sep 2010 13:18:50 +0100

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
> 

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

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 21 Sep 2010 13:38:00 +0200

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:[email-masked]] 
> Sent: den 13 september 2010 14:19
> To: Ingemar Johansson S
> Cc: iccrg; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: TFRC-SP and maximum packet rate
> 
> Hi,
> 
> > 
> > because TFRC Inter packet Interval may be difficult to 
> implement given 
> > various OS concerns). This would give a packet rate of ~170packets/s
> > 
> 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
> 
>

---

From: Soo-Hyun Choi <[email-masked]>
Date: Tue, 21 Sep 2010 12:58:33 +0100

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