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

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