Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Queuing algorithm to provide type-of-service for IP links (RFC1046)

IP.com Disclosure Number: IPCOM000001852D
Original Publication Date: 1988-Feb-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 9 page(s) / 28K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W. Prue: AUTHOR [+2]

Abstract

The Type-of-Service (TOS) field in IP headers allows one to chose from none to all the following service types; low delay, high throughput, and high reliability. It also has a portion allowing a priority selection from 0-7. To date, there is nothing describing what should be done with these parameters. This discussion proposes an approach to providing the different classes of service and priorities requestable in the TOS field.

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

Network Working Group W. Prue

Request for Comments: 1046 J. Postel

ISI

February 1988

A Queuing Algorithm to Provide Type-of-Service for IP Links

Status of this Memo

This memo is intended to explore how Type-of-Service might be

implemented in the Internet. The proposal describes a method of

queuing which can provide the different classes of service. The

technique also prohibits one class of service from consuming

excessive resources or excluding other classes of service. This is

an "idea paper" and discussion is strongly encouraged. Distribution

of this memo is unlimited.

Introduction

The Type-of-Service (TOS) field in IP headers allows one to chose

from none to all the following service types; low delay, high

throughput, and high reliability. It also has a portion allowing a

priority selection from 0-7. To date, there is nothing describing

what should be done with these parameters. This discussion proposes

an approach to providing the different classes of service and

priorities requestable in the TOS field.

Desired Attributes

We should first consider how we want these services to perform. We

must first assume that there is a demand for service that exceeds

current capabilities. If not, significant queues do not form and

queuing algorithms become superfluous.

The low delay class of service should have the ability to pass data

through the net faster than regular data. If a request is for low

delay class of service only, not high throughput or high reliability,

the Internet should provide low delay for relatively less throughput,

with less than high reliability. The requester is more concerned

with promptness of delivery than guaranteed delivery. The Internet

should provide a Maximum Guaranteed Delay (MGD) per node, or better,

if the datagram successfully traverses the Internet. In the worst

case, a datagram's arrival will be MGD times the number of nodes

traversed. A node is any packet switching element, including IP

gateways and ARPANET IMP's. The MGD bound will not be affected by

the amount of traffic in the net. During non-busy hours, the delay

provided should be better than the guarantee. If the delay a

satellite link introduces is less than the MGD, that link should be

considered in the route. If however, the MGD is less than the

satellite link can provide, it should not be used. For this

discussion it is assumed that delay for individual links are low

enough that a sending node can provide the MGD service.

Low delay class of service is not the same as low Round Trip Time

(RTT). Class of service is unidirectional. The datagrams responding

to low delay traffic (i.e., Acking the data) might be sent with a

high reliability class of service, but ...