 a digital infrastructure in place and that few errors will result from network transmission problems, such as noise or jitter. Therefore, the entire error detection and correction process has been removed from the Frame Relay network, and error control is done entirely in the endpoints. This means that traffic is not delayed by being stopped and checked, which translates to much faster throughput over Frame Relay networks than over X.25 networks. The lack of error control in the network also means that it is possible to carry voice and video over a Frame Relay network. However, Frame Relay is not innately designed to do that. The packet sizes enabled under Frame Relay are large-up to 4,096 bytes-and variable, which means that there could be a 100-byte packet going through a network node, with a 4,000-byte packet right behind it. When you have packets of varying sizes, you can't predict the delay in processing those pack- ets through the network, and when you can't predict the delay, you can't properly address the latency requirements of real-time voice or video. Yet it is possible, in fact, to run voice and video over Frame Relay networks by tweaking the system in one of several ways. For example, we could provision separate links to carry the voice and the data traffic, and thus some excess data bursting wouldn't affect any real-time telephony, for instance, that is under way. We could prioritize traffic by application and in that way enable access to bandwidth, based on priority. In pub- lic Frame Relay networks, we often convert frames to equal-sized cells. At the core of the Frame Relay network is ATM because ATM currently offers the strongest suite of tools for traffic management. Thus, many networks, including IP back- bones, the Internet, and Frame Relay, have ATM at their core. We can trick the sys- tem in order to get added utility out of Frame Relay networks, but keep in mind that when we do this, we lose a little bit of the cost-efficiencies we would otherwise have by running all our traffic in the sa