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

From: Ladan Gharai <[email-masked]>
Date: Sun, 8 Feb 2004 20:14:21 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Damon Lanphear <[email-masked]>
Date: Wed, 11 Feb 2004 14:27:19 -0800

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:

> (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.
> 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.
> standard RTP time stamp (which denotes sampling or presentation time) 
> - and would be able to compute the RTT itself (with the added bonus of 
> 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

---

From: Ladan Gharai <[email-masked]>
Date: Tue, 24 Feb 2004 18:45:02 -0500

On Feb 11, 2004, at 5:27 PM, Damon Lanphear wrote:

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

  Damon:

While I like the idea of using the RTCP RR for computing the loss event 
rate it raises two issues. First, TFRC Loss Intervals do not correlate 
exactly to the RTT, however I do not have any data as to how sensitive 
TFRC is to the difference between these two? Secondly, it would put the 
burden of computing the loss event rate on the sender - as opposed to 
the receiver, as intended in RFC3448.

The RTT calculations can be done by either the sender or receiver - but 
both the sender (for rate computation)  and the receiver (for loss 
event calculation -or- as in your scheme to send RTCP packets) need 
know what the current  RTT is. If  the RTT is computed by the 
sender/receiver, some mechanism is needed to convey it to the 
receiver/sender.

Ladan
>
> 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 
>> - and would be able to compute the RTT itself (with the added bonus 
>> of also providing it to the TFRC sender).