rfc1046.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 619 行 · 第 1/2 页

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






Prue & Postel                                                   [Page 2]

RFC 1046                Type-of-Service Queuing            February 1988


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



Prue & Postel                                                   [Page 3]

RFC 1046                Type-of-Service Queuing            February 1988


   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.



Prue & Postel                                                   [Page 4]

RFC 1046                Type-of-Service Queuing            February 1988


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



Prue & Postel                                                   [Page 5]

RFC 1046                Type-of-Service Queuing            February 1988


   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