Flow Control (Q90)

The information in this article applies to:

One challenge with H.323 is adjusting the transmission rate of the audio and video streams, which both use UDP, in order to minimize end-to-end packet loss while maximizing throughput and continuing to be a "good network citizen"-not using however much bandwidth you want at the expense of other users, who often must share the same network resources. Packet loss occurs in a couple of places. Most packet loss on a public packet-switched network, such as the Internet, occurs at the routers. When more packets arrive than a router can handle, it must discard them. Packets are also lost at the receiver when a transmitter sends data too fast for it to keep up. TCP handles these conditions quite well but is not appropriate for conversational services such as videoconferencing. That's why UDP is used for audio and video. It is unreliable but fast. Used with care, it does a good job of getting the data to the other end in a timely manner while minimizing packet loss. Here is an interesting paper by Jamshid Mahdavi and Sally Floyd on UDP rate control previously at http://www.psc.edu/networking/papers/tcp_friendly.html titled "TCP-Friendly Unicast Rate-Based Flow Control". A follow-on to that paper appears in RFC 3448.

In H.323, the maxBitRate field for video indicates the fastest that a receiver can accept data. However, it is an extremal-bound peak-rate traffic descriptor which provides a crude form of open-loop flow control. It is really only useful across networks where traffic is very smooth and predictable. Across a small corporate WAN, maybe; the Internet, no. It should therefore be set to as large a value as is sensible, based on what the EP knows of the connection, which is usually just the speed of the first network segment, if it even knows that much.