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

[Ladan Gharai <ladan at isi.edu>]

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