1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc1257.txt b/doc/rfc/rfc1257.txt
new file mode 100644
index 0000000..6101050
--- /dev/null
+++ b/doc/rfc/rfc1257.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                       C. Partridge
+Request for Comments: 1257         Swedish Institute of Computer Science
+                                                          September 1991
+
+
+   Isochronous Applications Do Not Require Jitter-Controlled Networks
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo argues that jitter control is not required for networks to
+   support isochronous applications.  A network providing bandwidth and
+   bounds delay is sufficient.  The implications for gigabit
+   internetworking protocols are briefly considered.
+
+Introduction
+
+   An oft-stated goal of many of the ongoing gigabit networking research
+   projects is to make it possible to support high bandwidth isochronous
+   applications.  An isochronous application is an application which
+   must generate or process regular amounts of data at fixed intervals.
+   Examples of such applications include telephones, which send and
+   receive voice samples at regular intervals, and fixed rate video-
+   codecs, which generate data at regular intervals and which must
+   receive data at regular intervals.
+
+   One of the properties of isochronous applications like voice and
+   video data streams is that their users may be sensitive to the
+   variation in interarrival times between data delivered to the final
+   output device.  This interarrival time is called "jitter" for very
+   small variances (less than 10 Hz) and "wander" if it is somewhat
+   larger (less than one day).  For convenience, this memo will use the
+   term jitter for both jitter and wander.
+
+   A couple of examples help illustrate the sensitivity of applications
+   to jitter.  Consider a user watching a video at her workstation.  If
+   the screen is not updated regularly every 30th of a second or faster,
+   the user will notice a flickering in the image.  Similarly, if voice
+   samples are not delivered at regular intervals, voice output may
+   sound distorted.  Thus the user is sensitive to the interarrival time
+   of data at the output device.
+
+   Observe that if two users are conferring with each other from their
+
+
+
+Partridge                                                       [Page 1]
+
+RFC 1257                 Isochronous and Jitter           September 1991
+
+
+   workstations, then beyond sensitivity to interarrival times, the
+   users will also be sensitive to end-to-end delay.  Consider the
+   difference between conferencing over a satellite link and a
+   terrestrial link.  Furthermore, for the data to be able to arrive in
+   time, there must be sufficient bandwidth.  Bandwidth requirements are
+   particularly important for video: HDTV, even after compression,
+   currently requires bandwidth in excess of 100 Mbits/second.
+
+   Because multimedia applications are sensitive to jitter, bandwidth
+   and delay, it has been suggested that the networks that carry
+   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 and
+   delay is sufficient to support networked multimedia applications.
+   Jitter control is not required.
+
+Isochrony without Jitter Control
+
+   The key argument of this memo is that an isochronous service can be
+   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 channel
+   between sender and receiver and at least the receiver knows what the
+   bound is.  (These assumptions come directly from our assertion that
+   the network can bound delay).  The term "channel" is used to mean
+   some amount of bandwidth delivered over some path between sender and
+   receiver.
+
+   Now imagine an operating system in which applications can be
+   scheduled to be active at regular intervals. Further assume that the
+   receiving application has buffer space equal to the channel bandwidth
+   times the maximum interarrival variance.  (Observe that the maximum
+   interarrival variance is always known - in the worst case, the
+   receiver can assume the maximum variance equals the maximum delay).
+
+   Now consider a situation in which the sender of the isochronous data
+   timestamps each piece of data when it is generated, using a universal
+   time source, and then sends the data to the receiver.  The receiver
+   reads a piece data in as soon as it is received and and places the
+   timestamped data into its buffer space.  The receiver processes each
+   piece of data only at the time equal to the data's timestamp plus the
+   maximum transit delay.
+
+   I argue that the receiver is processing data isochronously and thus
+   we have shown that a network need not be isochronous to support
+
+
+
+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 to
+   schedule applications to be active at regular intervals.  I will
+   argue that whether or not the network is isochronous, the operating
+   system must be able to schedule applications at regular intervals
+
+   Consider an isochronous network which delivers data with a tight
+   bound on jitter.  If the application on the receiving system does not
+   wake up when new data arrives, but waits until its next turn in the
+   processor, then the isochrony of the network service would be lost
+   due to the vagaries of operating system scheduling.  Thus, we may
+   reasonably expect that the operating system provides some mechanism
+   for waking up the application in response to a network interrupt for
+   a particular packet.  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.
+
+   Observe that the last paragraph suggests an application of the End-
+   To-End Principle [3].  Given that the operating system must provide a
+   mechanism sufficient for restoring isochrony, regardless of whether
+   the network is isochronous, it seems unreasonable to require the
+   network to redundantly provide the same service.
+
+   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.  The Network Time Protocol (NTP) has been widely tested
+   on the Internet and is capable of distributing time accurately to the
+   millisecond [4].  Its designer is currently contemplating the
+   possibility of distributing time accurate to the microsecond.
+
+Some Implications
+
+   The most important observation that can be made is that jitter
+
+
+
+Partridge                                                       [Page 3]
+
+RFC 1257                 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.  (There may exist networks that simply manage
+   delay and bandwidth. We know that's sufficient for multimedia
+   networking so our multimedia internetworking protocol should be
+   capable of running over those networks.  But if the multimedia
+   internetworking protocol requires control over jitter too, then
+   jitter control must be implemented on those subnetworks that don't
+   have it.  Implementing jitter control is clearly feasible - the
+   method for restoring jitter in the last section could be used on a
+   single network.  But if we know jitter control isn't needed, why
+   require networks to implement it?)
+
+   Note that the argument simply says that jitter control is not
+   required to support isochronous applications.  It may be the case
+   that jitter control is useful for other reasons.  For example, work
+   at Berkeley suggests that jitter control makes it possible to reduce
+   the amount of buffering required in intermediate network nodes [Y].
+   Thus, even if applications express their requirements only in terms
+   of bandwidth and delay, a network may find it useful to try to limit
+   jitter and thereby reduce the amount of memory required in each node.
+
+Acknowledgements
+
+   Thanks to the members of the End-To-End Interest mailing list who
+   provided a number of invaluable comments on this memo.
+
+References
+
+   [1] Leiner, B., Editor, "Critical Issues in High Bandwidth
+       Networking", Report to DARPA, August 1988.
+
+   [2] Ferrari, D., "Client Requirements for Real-Time Communication
+       Services", IEEE Communications Magazine, November 1990.  See also
+       RFC 1193, November, 1990.
+
+   [3] Saltzer, J., Reed D., and D. Clark, "End-To-End Arguments in
+       System Design", ACM Transactions on Computer Systems, Vol. 2, No.
+       4, November 1984.
+
+   [4] Mills, D., "Measured Performance of the Network Time Protocol in
+       the Internet System", RFC 1128, UDEL, October 1989.
+
+   [5] Verma, D., Zhang H., and D. Ferrari. "Guaranteeing Delay Jitter
+       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 Considertaions
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Craig Partridge
+   Swedish Institute of Computer Science
+   Box 1263
+   164 28 Kista
+   SWEDEN
+
+   Phone: +46 8 752 1524
+
+   EMail: craig@SICS.SE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Partridge                                                       [Page 5]
+
+\ No newline at end of file