Dismiss
IP.com applications will be updated on Sunday, March 5, from 11 am to 2 pm ET, to add new functionality and content. You may experience brief service interruptions during this period. We apologize for any inconvenience.
Browse Prior Art Database

Isochronous applications do not require jitter-controlled networks (RFC1257)

IP.com Disclosure Number: IPCOM000002074D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 4 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Partridge: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 29% of the total text.

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

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...