Subject: TFRC and RTP

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 10 Sep 2010 13:44:11 +0200

Hi

I am in the process where I try to understand TFRC (and the modifications like TFRC-SP and MulTFRC) better and in particular how they can be used with RTP.
RTP is assumed to use RTCP as feedback protocol. The rate of the RTCP feedback is given by the alloacted RTCP bandwidth, I would expect that in the majority of cases the time between RTCP is considerably longer than RTT.

This gives as I see it two potential problems
+ Estimation of RTT, RTT will be subsampled.
+ Loss events. The traditional RTCP report blocks does not make it possible to determine this reliably. The ECN for RTP draft (http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt) specifies a NACK feedback packet that can be transitted in early or immediate mode. This should make it possible to determine the loss events but the accuracy will then depend on the estimate of RTT.

Does anybody have an idea about how the limitations above (esp the subsampled RTT) will affect TFRC ?

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: Ingemar Johansson S <[email-masked]>
Date: Fri, 10 Sep 2010 14:37:38 +0200

Hi

Thanks for the prompt response. 
Yes it is true that one can use "Reduced size RTCP". In practice it would then mean that and RTCP SR (or RR) without the SDES-CNAME entity. The RTCP packets will anyway become relatively bulky and that will reduce the RTCP rate.

I will have a closer look at Colin's work

/Ingemar

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:[email-masked]] 
> Sent: den 10 september 2010 14:29
> To: Ingemar Johansson S
> Cc: [email-masked]; iccrg; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Iccrg] TFRC and RTP
> 
> Hi,
> 
> > 
> > I am in the process where I try to understand TFRC (and the 
> modifications like TFRC-SP and MulTFRC) better and in 
> particular how they can be used with RTP.
> > RTP is assumed to use RTCP as feedback protocol. The rate 
> of the RTCP feedback is given by the alloacted RTCP 
> bandwidth, I would expect that in the majority of cases the 
> time between RTCP is considerably longer than RTT.
> > 
> 
> You could potentially use your proposed standard to meet this 
> requirement? -- http://tools.ietf.org/html/rfc5506
> 
> 
> 
> > + Loss events. The traditional RTCP report blocks does not 
> make it possible to determine this reliably. The ECN for RTP 
> draft 
> (http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt) 
> specifies a NACK feedback packet that can be transitted in 
> early or immediate mode. This should make it possible to 
> determine the loss events but the accuracy will then depend 
> on the estimate of RTT.
> > 
> > Does anybody have an idea about how the limitations above 
> (esp the subsampled RTT) will affect TFRC ?
> > 
> 
> Because the measured RTT (SRTT) is inversely proportional to 
> the computed rate directly, the sub-sampled RTT would 
> certainly affect the calculated rate to some degree, e.g., it 
> could be of less smooth as one would hoped, or the computed 
> rate is limited by the sub-sampled RTT in a local LAN 
> environment (when RTT is extremely small).
> 
> The workaround to solve this might be (1) create a new 
> suitable AVPF packet to report RTT for TFRC feedback purpose 
> or (2) use an ack-clock based congestion control.
> 
> One of the students with Colin Perkins has investigated 
> similar problems to this earlier: http://csperkins.org/research/cc/
> -- see "TCP Friendly Rate Control" section there.
> 
> 
> Cheers,
> Soo-Hyun
> 
>

---

From: Soo-Hyun Choi <[email-masked]>
Date: Fri, 10 Sep 2010 13:28:51 +0100

Hi,

> Does anybody have an idea about how the limitations above (esp the subsampled RTT) will affect TFRC ?

Because the measured RTT (SRTT) is inversely proportional to the
computed rate directly, the sub-sampled RTT would certainly affect the
calculated rate to some degree, e.g., it could be of less smooth as one
would hoped, or the computed rate is limited by the sub-sampled RTT in a
local LAN environment (when RTT is extremely small).

The workaround to solve this might be (1) create a new suitable AVPF
packet to report RTT for TFRC feedback purpose or (2) use an ack-clock
based congestion control.

One of the students with Colin Perkins has investigated similar problems
to this earlier: http://csperkins.org/research/cc/
-- see "TCP Friendly Rate Control" section there.

Cheers,
Soo-Hyun