But if the operating system can wake up an application in response to an interrupt, it can just as easily wake the application in response to a clock interrupt at a particular time. Waking up to a clock interrupt provides the regular scheduling service we wanted. Another issue is the question of whether all receiving systems will have memory for buffering. For example, the telephone network is required to deliver its data isochronously because many telephones do not have memory. However, most receiving devices do have memory, and those devices, like telephones, that do not currently have memory seem likely to have memory in the future.
Many telephones have a modest amount of memory now.
Furthermore, even if the end nodes require isochronous traffic it is possible that last switch before delivery to the end node could provide the necessary buffer space to restore isochrony to the data flow. Readers may wonder if the assumption of a universal time source is reasonable. Isochronous and Jitter September 1991 control is not required for networks to be able to support isochronous applications. A corollary observation is that if we are to design an internetworking protocol for isochronous applications, that internetworking protocol should probably only offer control over delay and bandwidth. We know that's sufficient for multimedia networking so our multimedia internetworking protocol should be capable of running over those networks.