As per Relevance of the word bandwidth, we have this rfc below:
Network Working Group C.
Request for Comments: 1257 Swedish Institute of Computer
September 1991
Isochronous Applications Do Not Require Jitter-Controlled
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo argues that jitter control is not required for networks
support isochronous applications. A network providing bandwidth
bounds delay is sufficient. The implications for
internetworking protocols are briefly considered
An oft-stated goal of many of the ongoing gigabit networking
projects is to make it possible to support high bandwidth
applications. An isochronous application is an application
must generate or process regular amounts of data at fixed intervals
Examples of such applications include telephones, which send
receive voice samples at regular intervals, and fixed rate video
codecs, which generate data at regular intervals and which
receive data at regular intervals
One of the properties of isochronous applications like voice
video data streams is that their users may be sensitive to
variation in interarrival times between data delivered to the
output device. This interarrival time is called "jitter" for
small variances (less than 10 Hz) and "wander" if it is
larger (less than one day). For convenience, this memo will use
term jitter for both jitter and wander
A couple of examples help illustrate the sensitivity of
to jitter. Consider a user watching a video at her workstation.
the screen is not updated regularly every 30th of a second or faster
the user will notice a flickering in the image. Similarly, if
samples are not delivered at regular intervals, voice output
sound distorted. Thus the user is sensitive to the interarrival
of data at the output device
Observe that if two users are conferring with each other from
Partridge [Page 1]
RFC 1257 Isochronous and Jitter September 1991
workstations, then beyond sensitivity to interarrival times,
users will also be sensitive to end-to-end delay. Consider
difference between conferencing over a satellite link and
terrestrial link. Furthermore, for the data to be able to arrive
time, there must be sufficient bandwidth. Bandwidth requirements
particularly important for video: HDTV, even after compression
currently requires bandwidth in excess of 100 Mbits/second
Because multimedia applications are sensitive to jitter,
and delay, it has been suggested that the networks that
multimedia traffic must be able to allocate and control jitter
bandwidth and delay [1,2].
This memo argues that a network which simply controls bandwidth
delay is sufficient to support networked multimedia applications
Jitter control is not required
Isochrony without Jitter
The key argument of this memo is that an isochronous service can
provided by simply bounding the maximum delay through the network
To prove this argument, consider the following scenario
The network is able to bound the maximum transit delay on a
between sender and receiver and at least the receiver knows what
bound is. (These assumptions come directly from our assertion
the network can bound delay). The term "channel" is used to
some amount of bandwidth delivered over some path between sender
receiver
Now imagine an operating system in which applications can
scheduled to be active at regular intervals. Further assume that
receiving application has buffer space equal to the channel
times the maximum interarrival variance. (Observe that the
interarrival variance is always known - in the worst case,
receiver can assume the maximum variance equals the maximum delay).
Now consider a situation in which the sender of the isochronous
timestamps each piece of data when it is generated, using a
time source, and then sends the data to the receiver. The
reads a piece data in as soon as it is received and and places
timestamped data into its buffer space. The receiver processes
piece of data only at the time equal to the data's timestamp plus
maximum transit delay
I argue that the receiver is processing data isochronously and
we have shown that a network need not be isochronous to
Partridge [Page 2]
RFC 1257 Isochronous and Jitter September 1991
isochronous applications
A few issues have to be resolved to really make this proof stick
The first issue is whether the operating system can be expected
schedule applications to be active at regular intervals. I
argue that whether or not the network is isochronous, the
system must be able to schedule applications at regular
Consider an isochronous network which delivers data with a
bound on jitter. If the application on the receiving system does
wake up when new data arrives, but waits until its next turn in
processor, then the isochrony of the network service would be
due to the vagaries of operating system scheduling. Thus, we
reasonably expect that the operating system provides some
for waking up the application in response to a network interrupt
a particular packet. But if the operating system can wake up
application in response to an interrupt, it can just as easily
the application in response to a clock interrupt at a
time. Waking up to a clock interrupt provides the regular
service we wanted
Observe that the last paragraph suggests an application of the End
To-End Principle [3]. Given that the operating system must provide
mechanism sufficient for restoring isochrony, regardless of
the network is isochronous, it seems unreasonable to require
network to redundantly provide the same service
Another issue is the question of whether all receiving systems
have memory for buffering. For example, the telephone network
required to deliver its data isochronously because many telephones
not have memory. However, most receiving devices do have memory,
those devices, like telephones, that do not currently have
seem likely to have memory in the future. Many telephones have
modest amount of memory now. Furthermore, even if the end
require isochronous traffic it is possible that last switch
delivery to the end node could provide the necessary buffer space
restore isochrony to the data flow
Readers may wonder if the assumption of a universal time source
reasonable. The Network Time Protocol (NTP) has been widely
on the Internet and is capable of distributing time accurately to
millisecond [4]. Its designer is currently contemplating
possibility of distributing time accurate to the microsecond
Some
The most important observation that can be made is that
Partridge [Page 3]
RFC 1257 Isochronous and Jitter September 1991
control is not required for networks to be able to
isochronous applications. A corollary observation is that if we
to design an internetworking protocol for isochronous applications
that internetworking protocol should probably only offer control
delay and bandwidth. (There may exist networks that simply
delay and bandwidth. We know that's sufficient for
networking so our multimedia internetworking protocol should
capable of running over those networks. But if the
internetworking protocol requires control over jitter too,
jitter control must be implemented on those subnetworks that don'
have it. Implementing jitter control is clearly feasible -
method for restoring jitter in the last section could be used on
single network. But if we know jitter control isn't needed,
require networks to implement it?)
Note that the argument simply says that jitter control is
required to support isochronous applications. It may be the
that jitter control is useful for other reasons. For example,
at Berkeley suggests that jitter control makes it possible to
the amount of buffering required in intermediate network nodes [Y].
Thus, even if applications express their requirements only in
of bandwidth and delay, a network may find it useful to try to
jitter and thereby reduce the amount of memory required in each node
Thanks to the members of the End-To-End Interest mailing list
provided a number of invaluable comments on this memo
[1] Leiner, B., Editor, "Critical Issues in High
Networking", Report to DARPA, August 1988.
[2] Ferrari, D., "Client Requirements for Real-Time
Services", IEEE Communications Magazine, November 1990. See
RFC 1193, November, 1990.
[3] Saltzer, J., Reed D., and D. Clark, "End-To-End Arguments
System Design", ACM Transactions on Computer Systems, Vol. 2, No
4, November 1984.
[4] Mills, D., "Measured Performance of the Network Time Protocol
the Internet System", RFC 1128, UDEL, October 1989.
[5] Verma, D., Zhang H., and D. Ferrari. "Guaranteeing Delay
Bounds in Packet Switching Networks", Proceedings of TriComm '91,
Chapel Hill, North Carolina, April 1991.
Partridge [Page 4]
RFC 1257 Isochronous and Jitter September 1991
Security
Security issues are not discussed in this memo
Author's
Craig
Swedish Institute of Computer
Box 1263
164 28
Phone: +46 8 752 1524
EMail: craig@SICS.
Partridge [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
