RFC 1046 (rfc1046) - Page 1 of 11

Queuing algorithm to provide type-of-service for IP links

Alternative Format: Original Text Document
Next >
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
Next >