[Iccrg] TFRC and RTP

[Soo-Hyun Choi]

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



> 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 ?
> 

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