[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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