[Iccrg] TFRC and RTP

[Ingemar Johansson S]

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:S.Choi at cs.ucl.ac.uk] 
> Sent: den 10 september 2010 14:29
> To: Ingemar Johansson S
> Cc: tsvwg at ietf.org; iccrg; avt at ietf.org; 
> dragana.damjanovic at uibk.ac.at; steing at ifi.uio.no
> 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
> 
> 
> 
> > 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
> 
>