[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] IETF 60 AVT minutes -> RTP Profile for TCP Friendly Rate Control
Ladan Gharai <ladan at isi.edu> writes:
>> TCP-friendly feedback in RTP (especially using current RTCP) seems
>> to have some serious issues with reverse-path bandwidth costs. Unlike TCP
>> the acks are large and can't be piggybacked. While TFRC is supposed to
>> exist to "play nice" with other TCP and RTP streams (unlike raw RTP), the
>> additional reverse-channel bandwidth could conversely make things worse
>> (overall), especially on asymmetric links or in two-way communication.
>
>the reverse-path bandwidth costs is particularly problematic for low
>bandwidth flows and small RTTs (say <1Mbps with an RTT of 10 ms). This is
>currently an open issue and is discussed in latest version of the draft:
>draft-ietf-avt-tfrc-profile-02.txt (sections 8 and 9), specifically in
>section 9:
And especially bad for streams in the 10's or low 100's of Kbps
with relatively low RTT's (10's to 100ish).
>
> o RFC 3550 recommends that the percentage of control traffic
> relative to data, be fixed at 5%. For some flows, the feedback
> traffic for AVPCC may exceed this recommendation. Should AVPCC
> mandate a strict limit on the percentage of control traffic
> bandwidth? At what point is feedback too much feedback?
> (i.e., does it make sense for control traffic be 50% of data
> traffic?)
>
> What are the implications of this limit, in terms of congestion
> control, for flows which cannot abide by the limit? This is
> particularly the case for low bandwidth flows, under 1 Mbps, and
> RTTs of say less than 10 ms.
>
>
>there are two obvious ways to reduce the reverse path bandwidth: (1)
>sending smaller feedback packets; or (2) reducing the frequency of
>feedback packets. The second option would require investigating the impact
>of reduced feedback on TFRC dynamics.
Or 3) in unicast (of course) 2-way streams, use a small number of
bytes in the reverse path data stream. This could allow you to push
TCP-friendly rate control down to almost any bandwidth and RTT. Note that
VoIP and videophone streams are in this range, with RTT's in the low 10's to
150ish ms, and data bandwidths of 8-300Kbps (total BW of say 20-350K).
Targeting high-bitrate (1Mbps+) streams is all well and good, but
as things like VoIP increase in use the number of low and
moderate-bandwidth RTP/UDP streams on intermediate links increases
dramatically, making rate control all the more important for those streams.
You may have dozens or hundreds of these streams sharing a link (with a
fair bit of TCP data traffic, but the ratio of streams to TCP traffic will
be changing due to VoIP/etc).
>> For one-way communication, piggyback isn't feasible of course, but
>> TCP keeps ack sizes and bandwidth down compared to TFRC & RTCP. For
>> two-way communication though it might be possible to piggyback the
>> information in the RTP packets, at least a fair bit of the time, perhaps
>
> piggybacking was never really considered because it is complicated to
>satisfy both the feedback timing requirements and send packet rate (on the
>reverse path). And at any rate the receiver must send the RTCP feedback.
Yes, but the RTCP is rarely needed to be frequent with exception of
something like this. The "complication" here would be to piggyback it on
a data packet if the data packet goes out within some period of time of
when the packet being acked was received; otherwise an RTCP (or other)
packet would need to be sent. (For example, in variable-frame-rate
transmission or if there's silence suppression, or the equivalent.)
Without understanding better the algorithm here I can't comment on whether
this would work, but fundamentally it's not much different than scheduling
RTCP send-times.
>>> Discussion then moved onto the option of reducing the size of
>>> feedback messages by allowing them to be sent as non-compound RTCP
>>> packets. Stephan Wenger commented that this profile seems mostly
>>> useful for high bit-rate usage and in those cases, for any network
>>> with more than a single hop, the RTT will be large enough that the
>>> feedback will be order of magnitudes less then the forward
>>> traffic. To keep things simple it would be preferable not to
>>> introduce different processing rules for feedback packets versus
>>> other RTCP packet types. Stephen Casner also commented that with the
>>> intention of going to experimental, it seems unnecessary to do
>>> optimisations until we know that this actually works and have plans
>>> to go beyond an experimental status.
>>
>> Doesn't this involve some updating of RTP/RTCP stacks to make use
>> of this anyways? And I don't see how not _requiring_ sender/receiver
>> reports and SDES items in every RTCP packet noticably complicates the
>> processing of RTCP. Existing uses aren't affected because they're not
>> doing TFRC (though I wouldn't personally mind it spreading - for example
>> it would reduce the overhead for early RTCP feedback messages, doubly so
>> if you're trying to do ACKs with them.)
>
> I guess the difference would be that an RTCP packet for the AVPCC
>profile with the RR extensions could still be processed by an AVP stack?
>even though no congestion control would take place and the RR extensions
>would simply be ignored.
Since you're adding an RTT field to the RTP header, you can't talk
directly to an AVP (or any general non-AVPCC RTP) stack anyways. There is
a length field so the RTCP extensions to RR/SR should be ignored
("profile-specific extensions" as mentioned in RFC3550).
Also, according to RFC3550 you've stolen a bit from the payload type field
for "R" in RTP headers:
RFC 3550:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
TFRC draft:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M|R| PT | sequence number |
Also, it isn't even clear whether you stole it from PT or sequence number
because your divider is in the "middle" of a bit. If it's stolen from PT
you'll need to limit the payload values to <64 on a AVPCC media stream.
This 'R' bit and the RTP header is a serious inter-operation issue from
what I can see. Perhaps I'm missing something...
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rjesup at wgate.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt