Re: [AVT] New Draft: RTP Profile for TCP Friendly Rate Control

[Damon Lanphear <damonlan at real.com>]

It should be possible to implement a sender based variant of TFRC using 
the existing set of RTP protocol .  The RTT can be deduced from the RTCP 
RR at the sender, as can a loss event mapping.  A loss event is defined 
by TFRC as one or more packet losses in a single RTT.  If RTCP RRs are 
received once per RTT, then the loss event rate can be reasonably 
deduced using the difference in the RTCP RR cumulative loss field 
between consecuative RTCP RRs.

Ladan Gharai wrote:

> Dear AVT'ers:
>
> I have just submitted a new draft draft-gharai-avt-tfrc-profile-00.txt 
> to the Internet Drafts editor. The draft is also available on line at 
> http://www.east.isi.edu/projects/MACC/tfrc-profile.txt
>
> This is a preliminary draft for a RTP profile for TFRC,  "RTP/AVPCC". 
> Please read and comment on the draft, in particular on the following 
> two items:
>
> (I)     A TFRC receiver depends on  receiving  estimates of the 
> current RTT and the send time of each RTP packet, in order to compute 
> its loss event rate.
>         A simplistic approach to providing this information to the 
> receiver is to add fixed fields to the RTP data header. This approach 
> has a number of draw backs: (1) current implementations may not be 
> able to parse such packets; (2) additional overhead of 8 octets in 
> each data packet.
>        Ideally, a TFRC receiver would be able to make do with the 
> standard RTP time stamp (which denotes sampling or presentation time) 
> - and would be able to compute the RTT itself (with the added bonus of 
> also providing it to the TFRC sender).
>        This raises two questions: (1) does the RTP time stamp suffice 
> for loss event calculations? and (2) is it possible to have the 
> receiver compute RTTs?
>
>
> (II)      A  TFRC sender requires feedback at least once per RTT.  
> Depending on the data rate of a flow and the RTT, this TFRC 
> requirement may result in violation of RTCPs minimum interval and 
> bandwidth restrictions/recommendations. According to RFC3550  a 
> profile MAY specify control traffic bandwidth as a separate session 
> parameter. Is there a similar provision for profiles where the scaled 
> minimum RTCP interval does not suffice? (i.e. where does the profile 
> state that it cannot abide by the recommended minimum RTCP  interval?)
>
> Ladan Gharai
> http://www.east.isi.edu/~ladan
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt