Controlled-Load Service[#!controlled!#] provides approximately the same quality of service under heavy loads as under light loads,. A description of the traffic characteristics (the Tspec, described in 2.8.2) for the flow desiring Controlled-Load Service must be submitted to the router as for the case of Guaranteed Service although it is not necessary to include the peak rate parameter. If the flow is accepted for Controlled-Load Service then the router makes a commitment to offer the flow a service equivalent to that seen by a best-effort flow on a lightly loaded network. The important difference from the traditional Internet best-effort service is that the Controlled-Load flow does not noticeably deteriorate as the network load increases. This will be true regardless of the level of load increase. By contrast, a best-effort flow would experience progressively worse service (higher delay and, sooner or later, loss) as the network load increased. The Controlled-Load Service is intended for those classes of applications that can tolerate a certain amount of loss and delay provided it is kept to a reasonable level. Examples of applications in this category include adaptive real-time applications. Controlled Load has some fairly simple implementations, in terms of the queuing systems in routers. It also functions adequately for the existing Mbone applications, which can adapt to the modest (small) scale end-to-end delay and variations and jitter that it may introduce, through the use of adaptive playout buffering [#!rat!#]. It is not suited to applications that require very low latency (e.g. distributed VR systems and so forth).
One possible example of the use of the controlled load service is that of Mbone applications, over a private so-called Intranet, where traffic conditions and global policies can be managed such that a statistical throughput guarantee is enough, and propagation delays will be low enough that for most users, interactive software based multimedia conferencing tools will perform adequately. A more interesting example might be the provision of SNA or DEC LAT tunnelling across a public Internet Service Provider’s backbone network. SNA and DEC LAT are both somewhat delay sensitive due to their detailed protocol operations, although not as much as some real time systems are. However, using the same Internet path to carry them with arbitrary interference from other application's flows would not work well (or at all).
Next we discuss the service provided where the user requires some commitment to a delay guarantee, namely the Guaranteed Service.