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: 2019-Feb-15
Document File: 11 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W. Prue: AUTHOR [+1]

Related Documents

10.17487/RFC1046: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 12% 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

Prue & Postel [Page 1]

RFC 1046 Type-of-Service Queuing February 1988

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 not low delay.

The performance of TCP might be significantly improved with an accurate estimate of the round trip time and the retransmission timeout. The TCP retransmission timeout could be set to the maximum delay for the current r...

Processing...
Loading...