rfc2212.txt

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

RFC 2212             Guaranteed Quality of Service        September 1997


   shaping the amount of buffering required to handle the burstiness is
   bounded by b+Csum+Dsum*R.  If one accounts for the peak rate, this
   can be further reduced to

                  M + (b-M)(p-X)/(p-r) + (Csum/R + Dsum)X

   where X is set to r if (b-M)/(p-r) is less than Csum/R+Dsum and X is
   R if (b-M)/(p-r) is greater than or equal to Csum/R+Dsum and p>R;
   otherwise, X is set to p.  This reduction comes from the fact that
   the peak rate limits the rate at which the burst, b, can be placed in
   the network.  Conversely, if a non-zero slack term, Sout, is returned
   by the network element, the buffer requirements are increased by
   adding Sout to Dsum.

   While sending applications are encouraged to set the peak rate
   parameter and reshaping points are required to conform to it, it is
   always acceptable to ignore the peak rate for the purposes of
   computing buffer requirements and end-to-end delays.  The result is
   simply an overestimate of the buffering and delay.  As noted above,
   if the peak rate is unknown (and thus potentially infinite), the
   buffering required is b+Csum+Dsum*R.  The end-to-end delay without
   the peak rate is b/R+Ctot/R+Dtot.

   The parameter D for each network element SHOULD be set to the maximum
   datagram transfer delay variation (independent of rate and bucket
   size) through the network element.  For instance, in a simple router,
   one might compute the difference between the worst case and best case
   times it takes for a datagram to get through the input interface to
   the processor, and add it to any variation that may occur in how long
   it would take to get from the processor to the outbound link
   scheduler (assuming the queueing schemes work correctly).

   For weighted fair queueing in a datagram environment, D is set to the
   link MTU divided by the link bandwidth, to account for the
   possibility that a packet arrives just as a maximum-sized packet
   begins to be transmitted, and that the arriving packet should have
   departed before the maximum-sized packet.  For a frame-based, slotted
   system such as Stop and Go queueing, D is the maximum number of slots
   a datagram may have to wait before getting a chance to be
   transmitted.

   Note that multicasting may make determining D more difficult.  In
   many subnets, ATM being one example, the properties of the subnet may
   depend on the path taken from the multicast sender to the receiver.
   There are a number of possible approaches to this problem.  One is to






Shenker, et. al.            Standards Track                    [Page 16]

RFC 2212             Guaranteed Quality of Service        September 1997


   choose a representative latency for the overall subnet and set D to
   the (non-negative) difference from that latency.  Another is to
   estimate subnet properties at exit points from the subnet, since the
   exit point presumably is best placed to compute the properties of its
   path from the source.

      NOTE: It is important to note that there is no fixed set of rules
      about how a subnet determines its properties, and each subnet
      technology will have to develop its own set of procedures to
      accurately compute C and D and slack values.

   D is intended to be distinct from the latency through the network
   element.  Latency is the minimum time through the device (the speed
   of light delay in a fiber or the absolute minimum time it would take
   to move a packet through a router), while parameter D is intended to
   bound the variability in non-rate-based delay.  In practice, this
   distinction is sometimes arbitrary (the latency may be minimal) -- in
   such cases it is perfectly reasonable to combine the latency with D
   and to advertise any latency as zero.

      NOTE: It is implicit in this scheme that to get a complete
      guarantee of the maximum delay a packet might experience, a user
      of this service will need to know both the queueing delay
      (provided by C and D) and the latency.  The latency is not
      advertised by this service but is a general characterization
      parameter (advertised as specified in [8]).

      However, even if latency is not advertised, this service can still
      be used.  The simplest approach is to measure the delay
      experienced by the first packet (or the minimum delay of the first
      few packets) received and treat this delay value as an upper bound
      on the latency.

   The parameter C is the data backlog resulting from the vagaries of
   how a specific implementation deviates from a strict bit-by-bit
   service. So, for instance, for datagramized weighted fair queueing, C
   is set to M to account for packetization effects.

   If a network element uses a certain amount of slack, Si, to reduce
   the amount of resources that it has reserved for a particular flow,
   i, the value Si SHOULD be stored at the network element.
   Subsequently, if reservation refreshes are received for flow i, the
   network element MUST use the same slack Si without any further
   computation. This guarantees consistency in the reservation process.







Shenker, et. al.            Standards Track                    [Page 17]

RFC 2212             Guaranteed Quality of Service        September 1997


   As an example for the use of the slack term, consider the case where
   the required end-to-end delay, Dreq, is larger than the maximum delay
   of the fluid flow system. The latter is obtained by setting R=r in
   the fluid delay formula (for stability, R>=r must be true), and is
   given by

                           b/r + Ctot/r + Dtot.


   In this case the slack term is

                     S = Dreq - (b/r + Ctot/r + Dtot).


   The slack term may be used by the network elements to adjust their
   local reservations, so that they can admit flows that would otherwise
   have been rejected. A network element at an intermediate network
   element that can internally differentiate between delay and rate
   guarantees can now take advantage of this information to lower the
   amount of resources allocated to this flow. For example, by taking an
   amount of slack s <= S, an RCSD scheduler [5] can increase the local
   delay bound, d, assigned to the flow, to d+s. Given an RSpec, (Rin,
   Sin), it would do so by setting Rout = Rin and Sout = Sin - s.

   Similarly, a network element using a WFQ scheduler can decrease its
   local reservation from Rin to Rout by using some of the slack in the
   RSpec. This can be accomplished by using the transformation rules
   given in the previous section, that ensure that the reduced
   reservation level will not increase the overall end-to-end delay.

Evaluation Criteria

   The scheduling algorithm and admission control algorithm of the
   element MUST ensure that the delay bounds are never violated and
   datagrams are not lost, when a source's traffic conforms to the
   TSpec.  Furthermore, the element MUST ensure that misbehaving flows
   do not affect the service given to other flows.  Vendors are
   encouraged to formally prove that their implementation is an
   approximation of the fluid model.

Examples of Implementation

   Several algorithms and implementations exist that approximate the
   fluid model.  They include Weighted Fair Queueing (WFQ) [2], Jitter-
   EDD [3], Virtual Clock [4] and a scheme proposed by IBM [5].  A nice
   theoretical presentation that shows these schemes are part of a large
   class of algorithms can be found in [6].




Shenker, et. al.            Standards Track                    [Page 18]

RFC 2212             Guaranteed Quality of Service        September 1997


Examples of Use

   Consider an application that is intolerant of any lost or late
   datagrams.  It uses the advertised values Ctot and Dtot and the TSpec
   of the flow, to compute the resulting delay bound from a service
   request with rate R. Assuming R < p, it then sets its playback point
   to [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot.

Security Considerations

   This memo discusses how this service could be abused to permit denial
   of service attacks.  The service, as defined, does not allow denial
   of service (although service may degrade under certain
   circumstances).

Appendix 1: Use of the Guaranteed service with RSVP

   The use of guaranteed service in conjunction with the RSVP resource
   reservation setup protocol is specified in reference [9]. This
   document gives the format of RSVP FLOWSPEC, SENDER_TSPEC, and ADSPEC
   objects needed to support applications desiring guaranteed service
   and gives information about how RSVP processes those objects. The
   RSVP protocol itself is specified in Reference [10].

References

   [1] Shenker, S., and J. Wroclawski, "Network Element Service
   Specification Template", RFC 2216, September 1997.

   [2] A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of
   a Fair Queueing Algorithm," in Internetworking: Research and
   Experience, Vol 1, No. 1., pp. 3-26.

   [3] L. Zhang, "Virtual Clock: A New Traffic Control Algorithm for
   Packet Switching Networks," in Proc. ACM SIGCOMM '90, pp. 19-29.

   [4] D. Verma, H. Zhang, and D. Ferrari, "Guaranteeing Delay Jitter
   Bounds in Packet Switching Networks," in Proc. Tricomm '91.

   [5] L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan,
   "Efficient Network QoS Provisioning Based on per Node Traffic
   Shaping," IBM Research Report No. RC-20064.

   [6] P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End Delay
   Bounds in Heterogeneous Networks," in Proc. 5th Intl. Workshop on
   Network and Operating System Support for Digital Audio and Video,
   April 1995.




Shenker, et. al.            Standards Track                    [Page 19]

RFC 2212             Guaranteed Quality of Service        September 1997


   [7] A.K.J. Parekh, A Generalized Processor Sharing Approach to Flow
   Control in Integrated Services Networks, MIT Laboratory for
   Information and Decision Systems, Report LIDS-TH-2089, February 1992.

   [8] Shenker, S., and J. Wroclawski, "General Characterization
   Parameters for Integrated Service Network Elements", RFC 2215,
   September 1997.

   [9] Wroclawski, J., "Use of RSVP with IETF Integrated Services", RFC
   2210, September 1997.

   [10] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP)
   - Version 1 Functional Specification", RFC 2205, September 1997.

Authors' Addresses

   Scott Shenker
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA  94304-1314

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Craig Partridge
   BBN
   2370 Amherst St
   Palo Alto CA 94306

   EMail: [e-mail]


   Roch Guerin
   IBM T.J. Watson Research Center
   Yorktown Heights, NY 10598

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]










Shenker, et. al.            Standards Track                    [Page 20]