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 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 route (if the current route could be
   determined).  The timeout value would have to be redetermined when
   the number of hops in the route changes.

   High throughput class of service should get a large volume of data
   through the Internet.  Requesters of this class are less concerned
   with the delay the datagrams have crossing the Internet and the
   reliability of their delivery.  This type of traffic might be served
   well by a satellite link, especially if the bandwidth is high.
   Another attribute this class might have is consistent one way
   traversal time for a given burst of datagrams.  This class of service
   will have its traversal times affected by the amount of Internet
   load.  As the Internet load goes up, the throughput for each source
   will go down.

   High reliability class of service should see most of its datagrams
   delivered if the Internet is not too heavily loaded.  Source Quenches
   (SQ) should not be sent only when datagrams are discarded.  SQs
   should be sent well before the queues become full, to advise the
   sender of the rate that can be currently supported.

   Priority service should allow data that has a higher priority to be
   queued ahead of other lower priority data.  It is important to limit
   the amount of priority data.  The amount of preemption a lower
   priority datagram suffers must also be limited.

   It is assumed that a queuing algorithm provides these classes of
   service.  For one facility to be used over another, that is, making
   different routing decisions based upon the TOS, requires a more
   sophisticated routing algorithm and larger routing database.  These
   issues are not discussed in this document.

Applications for Class of Service

   The following are examples of how classes of service might be used.
   They do not necessarily represent the best choices, but are presented
   only to illustrate how the different classes of service might be used
   to advantage.

   Interactive timesharing access using a line-at-a-time or character-
   at-a-time terminal (TTY) type of access is typically low volume
   typing speed input with low or high volume output.  Some Internet
   applications use echoplex or character by character echoing of user
   input by the destination host.  PC devices also have local files that
   may be uploaded to remote hosts in a streaming mode.  Supporting such
   traffic can require several types of service.  User keyboard input
   should be forwarded with low delay.  If echoplex is used, all user
   characters sent and echoed should be low delay to minimize the
   echoing delay.  The computer responses should be regular or high
   throughput depending upon the volume of data sent and the speed of
   the output device.  If the computer response is a single datagram of
   data, the user should get low delay for the response, to minimize the
   human/computer interaction time.  If however the output takes a while
   to read and digest, low delay computer responses are a waste of
   Internet resources.  When streaming input is being sent the data
   should be sent requesting high throughput or regular class of
   service.

   The IBM 3270 class of terminals typically have traffic volumes
   greater than TTY access.  Echoplex is not needed.  The output devices
   usually handle higher speed output streams and most sites do not have
   the ability to stream input.  Input is typically a screen at a time,
   but some PC implementations of 3270 use a variation of the protocol
   to effectively stream in volumes of data.  Low delay for low volume
   input and output is appropriate.  High throughput is appropriate for
   the higher volume traffic.

   Applications that transfer high volumes of data are typically
   streaming in one direction only, with acks for the data, on the
   return path.  The data transfer should be high throughput and the
   acks should probably be regular class of service.  Transfer
   initiation and termination might be served best with low delay class
   of service.

   Requests to, and responses from a time service might use low delay
   class of service effectively.

   These suggestions for class of service usage implies that the
   application sets the service based on the knowledge it has during the
   session.  Thus, the application should have control of this setting

   dynamically for each send data request, not just on a per
   session/conversation/transaction basis.  It would be possible for the
   transport level protocol to guess (i.e., TCP), but it would be sub-
   optimal.

Algorithm

   When we provide class of service queuing, one class may be more
   desirable than the others.  We must limit the amount of resources
   each class consumes when there is contention, so the other classes
   may also operate effectively.  To be fair, the algorithm provides the
   requested service by reducing the other service attributes.  A
   request for multiple classes of service is an OR type of request not
   an AND request.  For example, one can not get low delay and high
   throughput unless there is no contention for the available resources.

Low Delay Queuing

   To support low delay, use a limited queue so requests will not wait
   longer than the MGD on the queue.  The low delay queue should be
   serviced at a lower rate than other classes of service, so low delay
   requests will not consume excessive resources.  If the number of low
   delay datagrams exceeds the queue limit, discard the datagrams.  The
   service rate should be low enough so that other data can still get
   through. (See discussion of service rates below.)  Make the queue
   limit small enough so that, if the datagram is queued, it will have a
   guaranteed transit time (MGD).  It seems unlikely that Source Quench
   flow control mechanisms will be an effective method of flow control
   because of the small size of the queue.  It should not be done for
   this class of service.  Instead, datagrams should just be discarded
   as required.  If the bandwidth or percentage allocated to low delay
   is such that a large queue is possible (see formula below), SQs
   should be reconsidered.

   The maximum delay a datagram with low delay class of service will
   experience (MGD), can be determined with the following information:

      N = Queue size for low delay queue
      P = Percentage of link resources allocated to low delay
      R = Link rate (in datagrams/sec.)
                      N
      Max Delay =   -----
                    P * R

   If Max Delay is held fixed, then as P and R go up, so does N.  It is
   probable that low delay service datagrams will prove to be, on the
   average, smaller than other traffic.  This means that the number of
   datagrams that can be sent in the allocated bandwidth can be larger.

High Reliability Queuing

   To support high reliability class of service, use a queue that is
   longer than normal (longer queue means higher potential delay).  Send
   SQ earlier (smaller percentage of max queue length) and don't discard
   datagrams until the queue is full.  This queue should have a lower
   service rate than high throughput class of service.

   Users of this class of service should specify a Time-to-Live (TTL)
   which is made appropriately longer so that it will survive longer
   queueing times for this class of service.

   This queuing procedure will only be effective for Internet
   unreliability due to congestion.  Other Internet unreliability
   problems such as high error rate links or reliability features such
   as forward error correcting modems must be dealt with by more
   sophisticated routing algorithms.

High Throughput Queuing

   To support high throughput class of service have a queue that is
   treated like current IP queuing.  It should have the highest service
   rate.  It will experience higher average through node delay than low
   delay because of the larger queue size.

   Another thing that might be done, is to keep datagrams of the same
   burst together when possible.  This must be done in a way that will
   not block other traffic.  The idea is to deliver all the data to the
   other end in a contiguous burst.  This could be an advantage by
   allowing piggybacking acks for the whole burst at one time.  This
   makes some assumptions about the overlying protocol which may be
   inappropriate.

Regular Service Queuing

   For datagrams which request none of the three classes of service,
   queue the datagrams on the queue representing the least delay between
   the two queues, the high throughput queue or the high reliability
   queue.  If one queue becomes full, queue on the other.  If both
   queues are full, follow the source quench procedure for regular class
   of service (see RFC-1016), not the procedure for the queue the
   datagram failed to attain.

   In the discussion of service rates described below, it is proposed
   that the high throughput queue get service three times for every two
   times for the high reliability queue.  Therefore, the queue length of
   the high reliability queue should be increased by 50% (in this
   example) to compare the lengths of the two queues more accurately.  A

   simplification to this method is to just queue new data on the queue
   that is the shortest.  The slower service rate queue will quickly
   exceed the size of the faster service rate queue and new data will go
   on the proper queue.  This however, would lead to more packet
   reordering than the first method.

Service Rates

   In this discussion, a higher service rate means that a queue, when
   non-empty, will consume a larger percentage of the available
   bandwidth than a lower service rate queue.  It will not block a lower
   service rate queue even if it is always full.

   For example, the service pattern could be; send low delay 17% of the
   time, high throughput 50% of the time, and high reliability 33% of
   the time.  Throughput requires the most bandwidth and high
   reliability requires medium bandwidth.  One could achieve this split
   using a pattern of L, R,R, T,T,T, where low delay is "L", high
   reliability is "R", and high throughput is "T'.  We want to keep the
   high throughput datagrams together.  We therefore send all of the
   high throughput data at one time, that is, not interspersed with the
   other classes of service.  By keeping all of the high throughput data
   together, we may help higher level protocols, such as TCP, as
   described above.  This would still be done in a way to not exceed the
   allowed service rate of the available bandwidth.

   These service rates are suggestions.  Some simplifications can be
   considered, such as having only two routing classes; low delay, and
   other.

Priority

   There is the ability to select 8 levels of priority 0-7, in addition
   to the class of service selected.  To provide this without blocking
   the least priority requests, we must give preempted datagrams
   frustration points every time a higher priority request cuts in line
   in front of it.  Thus if a datagram with low priority waits, it will
   always get through even when competing against the highest priority
   requests.  This assumes the TTL (Time-to-Live) field does not expire.

   When a datagram with priority arrives at a node, the node will queue
   the datagram on the appropriate queue ahead of all datagrams with
   lower priority.  Each datagram that was preempted gets its priority
   raised (locally).  The priority data will not bump a lower priority
   datagram off its queue, discarding the data.  If the queue is full,
   the newest data (priority or not) will be discarded.  The priority
   preemption will preempt only within the class of service queue to

   which the priority data is targeted.  A request specifying regular
   class of service, will contend on the queue where it is placed, high
   throughput or high reliability.

   An implementation strategy is to multiply the requested priority by 2
   or 4, then store the value in a buffer overhead area.  Each time the
   datagram is preempted, increment the value by one.  Looking at an
   example, assume we use a multiplier of 2.  A priority 6 buffer will
   have an initial local value of 12.  A new priority 7 datagram would
   have a local value of 14.  If 2 priority 7 datagrams arrive,
   preempting the priority 6 datagram, its local value is incremented to
   14.  It can no longer be preempted.  After that, it has the same
   local value as a priority 7 datagram and will no longer be preempted
   within this node.  In our example, this means that a priority 0
   datagram can be preempted by no more than 14 higher priority
   datagrams.  The priority is raised only locally in the node.  The
   datagram could again be preempted in the next node on the route.

   Priority queuing changes the effects we were obtaining with the low
   delay queuing described above.  Once a buffer was queued, the delay
   that a datagram would see could be determined.  When we accepted low
   delay data, we could guarantee a certain maximum delay.  With this
   addition, if the datagram requesting low delay does not also request
   high priority, the guaranteed delay can vary a lot more.  It could be
   1 up to 28 times as much as without priority queuing.

Discussion and Details

   If a low delay queue is for a satellite link (or any high delay
   link), the max queue size should be reduced by the number of
   datagrams that can be forwarded from the queue during the one way
   delay for the link.  That is, if the service rate for the low delay
   queue is L datagrams per second, the delay added by the high delay
   link is D seconds and M is the max delay per node allowed (MGD) in
   seconds, then the maximum queue size should be:

         Max Queue Size = L ( M - D),  M > D
                        = 0         ,  M <= D

   If the result is negative (M is less than the delay introduced by the
   link), then the maximum queue size should be zero because the link
   could never provide a delay less than the guaranteed M value.  If the
   bandwidth is high (as in T1 links), the delay introduced by a
   terrestrial link and the terminating equipment could be significant
   and greater than the average service time for a single datagram on
   the low delay queue.  If so, this formula should be used to reduce
   the queue size as well.  Note that this is reducing the queue size
   and is not the same as the allocated bandwidth.  Even though the

   queue size is reduced, the chit scheme described below will give low
   delay requesters a chance to use the allocated bandwidth.

   If a datagram requests multiple classes of service, only one class
   can be provided.  For example, when both low delay and high
   reliability classes are requested, and if the low delay queue is
   full, queue the data on the high reliability queue instead.  If we
   are able to queue the data on the low delay queue, then the datagram
   gets part of the high reliability service it also requested, because,
   once data is queued, data will not be discarded.  However, the
   datagram will be routed as a low delay request.  The same scheme is
   used for any other combinations of service requested.  The order of
   selection for classes of service when more than one is requested
   would be low delay, high throughput, then high reliability.  If a
   block of datagrams request multiple classes of service, it is quite
   possible that datagram reordering will occur.  If one queue is full
   causing the other queue to be used for some of the data, data will be
   forwarded at different service rates.  Requesting multiple classes of
   service gives the data a better chance of making it through the net
   because they have multiple chances of getting on a service queue.
   However, the datagrams pay the penalty of possible reordering and
   more variability in the one way transmission times.

   Besides total buffer consumption, individual class of service queue
   sizes should be used to SQ those asking for service except as noted
   above.

   A request for regular class of service is handled by queuing to the
   high reliability or high throughput queues evenly (proportional to
   the service rates of queue).  The low delay queue should only receive
   data with the low delay service type.  Its queue is too small to
   accept other traffic.

   Because of the small queue size for low delay suggested above, it is
   difficult for low delay service requests to consume the bandwidth
   allocated.  To do so, low delay users must keep the small queue
   continuously non-empty.  This is hard to do with a small queue.
   Traffic flow has been shown to be bursty in nature.  In order for the
   low delay queue to be able to consume the allocated bandwidth, a
   count of the various types being forwarded should be kept.  The
   service rate should increase if the actual percentage falls too low
   for the low delay queue.  The measure of service rates would have to
   be smoothed over time.

   While this does sound complicated, a reasonably efficient way can be
   described.  Every Q seconds, where Q is less than or equal to the
   MGD, each class gets N M P chits proportional to their allowed
   percentage.  Send data for the low delay queue up to the number of

   chits it receives decrementing the chits as datagrams are sent.  Next
   send from the high reliability queue as many as it has chits for.
   Finally, send from the high throughput queue.  At this point, each
   queue gets N M P chits again.  If the low delay queue does not
   consume all of its chits, when a low delay datagram arrives, before
   chit replenishment, send from the low delay queue immediately.  This
   provides some smoothing of the actual bandwidth made available for
   low delay traffic.  If operational experience shows that low delay
   requests are experiencing excessive congestion loss but still not
   consuming the classes allocated bandwidth, adjustments should be
   made.  The service rates should be made larger and the queue sizes
   adjusted accordingly.  This is more important on lower speed links
   where the above formula makes the queue small.

   What we should see during the Q seconds is that low delay data will
   be sent as soon as possible (as long as the volume is below the
   allowed percentage).  Also, the tendency will be to send all the high
   throughput datagrams contiguously.  This will give a more regular
   measured round trip time for bursts of datagrams.  Classes of service
   will tend to be grouped together at each intermediate node in the
   route.  If all of the queues with datagrams have consumed all of
   their allocated chits, but one or more classes with empty queues have
   unused chits then a percentage of these left over chits should be
   carried over.  Divide the remaining chit counts by two (with round
   down), then add in the refresh chit counts.  This allows a 50% carry
   over for the next interval.  The carry over is self limiting to less
   than or equal to the refresh chit count.  This prevents excessive
   build up.  It provides some smoothing of the percentage allocation
   over time but will not allow an unused queue to build up chits
   indefinitely.  No timer is required.

   If only a simple subset of the described algorithm is to be
   implemented, then low delay queuing would be the best choice.  One
   should use a small queue.  Service the queue with a high service rate
   but restrict the bandwidth to a small reasonable percentage of the
   available bandwidth.  Currently, wide area networks with high traffic
   volumes do not provide low delay service unless low delay requests
   are able to preempt other traffic.

Applicability

   When the output speed and volume match the input speed and volume,
   queues don't get large.  If the queues never grow large enough to
   exceed the guaranteed low delay performance, no queuing algorithm
   other than first in, first out, should be used.

   The algorithm could be turned on when the main queue size exceeds a
   certain threshold.  The routing node can periodically check for queue

   build up.  This queuing algorithm can be turned on when the maximum
   delays will exceed the allowed nodal delay for low delay class of
   service.  It can also be turned off when queue sizes are no longer a
   problem.

Issues

   Several issues need to be addressed before type of service queuing as
   described should be implemented.  What percentage of the bandwidth
   should each class of service consume assuming an infinite supply of
   each class of service datagrams?  What maximum delay (MGD) should be
   guaranteed per node for low delay datagrams?

   It is possible to provide a more optimal route if the queue sizes for
   each class of service are considered in the routing decision.  This,
   however, adds additional overhead and complexity to each routing
   node.  This may be an unacceptable additional complexity.

   How are we going to limit the use of more desirable classes of
   service and higher priorities?  The algorithm limits use of the
   various classes by restricting queue sizes especially the low delay
   queue size.  This helps but it seems likely we will want to
   instrument the number of datagrams requesting each Type-of-Service
   and priority.  When a datagram requests multiple classes of service,
   increment the instrumentation count once based upon the queue
   actually used, selecting, low delay, high throughput, high
   reliability, then regular.  If instrumentation reveals an excessive
   imbalance, Internet operations can give this to administrators to
   handle.  This instrumentation will show the distribution for types of
   service requested by the Internet users.  This information can be
   used to tune the Internet to service the user demands.

   Will the routing algorithms in use today have problems when routing
   data with this algorithm?  Simulation tests need to be done to model
   how the Internet will react.  If, for example, an application
   requests multiple classes of service, round trip times may fluctuate
   significantly.  Would TCP have to be more sophisticated in its round
   trip time estimator?

   An objection to this type of queuing algorithm is that it is making
   the routing and queuing more complicated.  There is current interest
   in high speed packet switches which have very little protocol
   overhead when handling/routing packets.  This algorithm complicates
   not simplifies the protocol.  The bandwidth being made available is
   increasing.  More T1 (1.5 Mbps) and higher speed links are being used
   all the time.  However, in the history of communications, it seems
   that the demand for bandwidth has always exceeded the supply.  When
   there is wide spread use of optical fiber we may temporarily

   experience a glut of capacity.  As soon as 1 gigabit optical fiber
   link becomes reasonably priced, new applications will be created to
   consume it all.  A single full motion high resolution color image
   system can consume, as an upper limit, nearly a gigabit per second
   channel (30 fps X 24 b/pixel X 1024 X 1024 pixels).

   In the study of one gateway, Dave Clark discovered that the per
   datagram processing of the IP header constituted about 20% of the
   processing time.  Much of the time per datagram was spent on
   restarting input, starting output and queuing datagrams.  He thought
   that a small additional amount of processing to support Type-of-
   Service would be reasonable.  He suggests that even if the code does
   slow the gateway down, we need to see if TOS is good for anything, so
   this experiment is valuable.  To support the new high speed
   communications of the near future, Dave wants to see switches which
   will run one to two orders of magnitude faster.  This can not be done
   by trimming a few instructions here or there.

   From a practical perspective, the problem this algorithm is trying to
   solve is the lack of low delay service through the Internet today.
   Implementing only the low delay queuing portion of this algorithm
   would allow the Internet to provide a class of service it otherwise
   could not provide.  Requesters of this class of service would not get
   it for free.  Low delay class of datagram streams get low delay at
   the cost of reliability and throughput.