This topic made me think about the starvation stuff. I suppose it is pretty obvious that UDP wouldn't back off if WRED was employed, but it's something I never really thought about.
I found a few good videos on YouTube which gave some good RTP/RTCP overviews.
1.1.f (i) Starvation
TCP Starvation / UDP Dominance is experienced in times of congestion where UDP and TCP streams are assigned to the same class. Because UDP has no flow control causing it to back off in the event of congestion, but TCP does, TCP ends up backing off and allowing even more bandwidth to UDP streams to the point where UDP takes over completely. This is not helped by WRED, as the drops caused by WRED would not affect UDP streams.
The best way to resolve this is to classify UDP and TCP streams separately as much as possible.
1.1.f (ii) Latency
Latency is end-to-end delay. UDP is connectionless, the only real effect of latency on UDP streams is that there will be a greater delay between sender and receiver. Jitter is the variance in latency – this causes problems for UDP streams. Jitter is smoothed by buffering.
1.1.f (iii) RTP/RTCP concepts
Real-time transport protocol. Encapsulated in UDP – keeps it faster and more “real-time”. Can’t afford to wait for retransmits / re-order packets, etc.
Real-time Transport Control Protocol. Provides feedback on the quality of the RTP stream. QoS, packet counts, Jitter, RTT, etc.