rfc1633.txt

<VC++网络游戏建摸与实现>源代码

         presumed lower cost of the service.  Furthermore, because many
         of the tolerant applications are adaptive, we augment the
         predictive service to also give "minimax" service, which is to
         attempt to minimize the ex post maximum delay.  This service is
         not trying to minimize the delay of every packet, but rather is
         trying to pull in the tail of the delay distribution.

         It is clear that given a choice, with all other things being
         equal, an application would perform no worse with absolutely
         reliable bounds than with fairly reliable bounds.  Why, then,
         do we offer predictive service?  The key consideration here is
         efficiency; when one relaxes the service requirements from
         perfectly to fairly reliable bounds, this increases the level
         of network utilization that can be sustained, and thus the
         price of the predictive service will presumably be lower than
         that of guaranteed service.  The predictive service class is
         motivated by the conjecture that the performance penalty will
         be small for tolerant applications but the overall efficiency
         gain will be quite large.

         In order to provide a delay bound, the nature of the traffic
         from the source must be characterized, and there must be some
         admission control algorithm which insures that a requested flow



Braden, Clark & Shenker                                        [Page 14]

RFC 1633            Integrated Services Architecture           June 1994


         can actually be accommodated. A fundamental point of our
         overall architecture is that traffic characterization and
         admission control are necessary for these real-time delay bound
         services.  So far we have assumed that an application's data
         generation process is an intrinsic property unaffected by the
         network.  However, there are likely to be many audio and video
         applications which can adjust their coding scheme and thus can
         alter the resulting data generation process depending on the
         network service available.  This alteration of the coding
         scheme will present a tradeoff between fidelity (of the coding
         scheme itself, not of the playback process) and the bandwidth
         requirements of the flow.  Such "rate-adaptive" playback
         applications have the advantage that they can adjust to the
         current network conditions not just by resetting their playback
         point but also by adjusting the traffic pattern itself.  For
         rate-adaptive applications, the traffic characterizations used
         in the service commitment are not immutable.  We can thus
         augment the service model by allowing the network to notify
         (either implicitly through packet drops or explicitly through
         control packets) rate-adaptive applications to change their
         traffic characterization.

      3.1.2 Elastic Applications

         While real-time applications do not wait for late data to
         arrive, elastic applications will always wait for data to
         arrive.  It is not that these applications are insensitive to
         delay; to the contrary, significantly increasing the delay of a
         packet will often harm the application's performance.  Rather,
         the key point is that the application typically uses the
         arriving data immediately, rather than buffering it for some
         later time, and will always choose to wait for the incoming
         data rather than proceed without it.  Because arriving data can
         be used immediately, these applications do not require any a
         priori characterization of the service in order for the
         application to function.  Generally speaking, it is likely that
         for a given distribution of packet delays, the perceived
         performance of elastic applications will depend more on the
         average delay than on the tail of the delay distribution.  One
         can think of several categories of such elastic applications:
         interactive burst (Telnet, X, NFS), interactive bulk transfer
         (FTP), and asynchronous bulk transfer (electronic mail, FAX).
         The delay requirements of these elastic applications vary from
         rather demanding for interactive burst applications to rather
         lax for asynchronous bulk transfer, with interactive bulk
         transfer being intermediate between them.





Braden, Clark & Shenker                                        [Page 15]

RFC 1633            Integrated Services Architecture           June 1994


         An appropriate service model for elastic applications is to
         provide "as-soon-as-possible", or ASAP service. (For
         compatibility with historical usage, we will use the term
         best-effort service when referring to ASAP service.).  We
         furthermore propose to offer several classes of best-effort
         service to reflect the relative delay sensitivities of
         different elastic applications.  This service model allows
         interactive burst applications to have lower delays than
         interactive bulk applications, which in turn would have lower
         delays than asynchronous bulk applications.  In contrast to the
         real-time service models, applications using this service are
         not subject to admission control.

         The taxonomy of applications into tolerant playback, intolerant
         playback, and elastic is neither exact nor complete, but was
         only used to guide the development of the core service model.
         The resulting core service model should be judged not on the
         validity of the underlying taxonomy but rather on its ability
         to adequately meet the needs of the entire spectrum of
         applications.  In particular, not all real-time applications
         are playback applications; for example, one might imagine a
         visualization application which merely displayed the image
         encoded in each packet whenever it arrived.  However, non-
         playback applications can still use either the guaranteed or
         predictive real-time service model, although these services are
         not specifically tailored to their needs.  Similarly, playback
         applications cannot be neatly classified as either tolerant or
         intolerant, but rather fall along a continuum; offering both
         guaranteed and predictive service allows applications to make
         their own tradeoff between fidelity, latency, and cost.
         Despite these obvious deficiencies in the taxonomy, we expect
         that it describes the service requirements of current and
         future applications well enough so that our core service model
         can adequately meet all application needs.

   3.2 Resource-Sharing Requirements and Service Models

      The last section considered quality of service commitments; these
      commitments dictate how the network must allocate its resources
      among the individual flows.  This allocation of resources is
      typically negotiated on a flow-by-flow basis as each flow requests
      admission to the network, and does not address any of the policy
      issues that arise when one looks at collections of flows.  To
      address these collective policy issues, we now discuss resource-
      sharing service commitments.  Recall that for individual quality
      of service commitments we focused on delay as the only quantity of
      interest.  Here, we postulate that the quantity of primary
      interest in resource-sharing is aggregate bandwidth on individual



Braden, Clark & Shenker                                        [Page 16]

RFC 1633            Integrated Services Architecture           June 1994


      links.  Thus, this component of the service model, called "link-
      sharing", addresses the question of how to share the aggregate
      bandwidth of a link among various collective entities according to
      some set of specified shares.  There are several examples that are
      commonly used to explain the requirement of link-sharing among
      collective entities.

      Multi-entity link-sharing. -- A link may be purchased and used
      jointly by several organizations, government agencies or the like.
      They may wish to insure that under overload the link is shared in
      a controlled way, perhaps in proportion to the capital investment
      of each entity.  At the same time, they might wish that when the
      link is underloaded, any one of the entities could utilize all the
      idle bandwidth.

      Multi-protocol link-sharing -- In a multi-protocol Internet, it
      may be desired to prevent one protocol family (DECnet, IP, IPX,
      OSI, SNA, etc.) from overloading the link and excluding the other
      families. This is important because different families may have
      different methods of detecting and responding to congestion, and
      some methods may be more "aggressive" than others. This could lead
      to a situation in which one protocol backs off more rapidly than
      another under congestion, and ends up getting no bandwidth.
      Explicit control in the router may be required to correct this.
      Again, one might expect that this control should apply only under
      overload, while permitting an idle link to be used in any
      proportion.

      Multi-service sharing -- Within a protocol family such as IP, an
      administrator might wish to limit the fraction of bandwidth
      allocated to various service classes.  For example, an
      administrator might wish to limit the amount of real-time traffic
      to some fraction of the link, to avoid preempting elastic traffic
      such as FTP.

      In general terms, the link-sharing service model is to share the
      aggregate bandwidth according to some specified shares.  We can
      extend this link-sharing service model to a hierarchical version.
      For instance, a link could be divided between a number of
      organizations, each of which would divide the resulting allocation
      among a number of protocols, each of which would be divided among
      a number of services.  Here, the sharing is defined by a tree with
      shares assigned to each leaf node.

      An idealized fluid model of instantaneous link-sharing with
      proportional sharing of excess is the fluid processor sharing
      model (introduced in [DKS89] and further explored in [Parekh92]
      and generalized to the hierarchical case) where at every instant



Braden, Clark & Shenker                                        [Page 17]

RFC 1633            Integrated Services Architecture           June 1994


      the available bandwidth is shared between the active entities
      (i.e., those having packets in the queue) in proportion to the
      assigned shares of the resource.  This fluid model exhibits the
      desired policy behavior but is, of course, an unrealistic
      idealization.  We then propose that the actual service model
      should be to approximate, as closely as possible, the bandwidth
      shares produced by this ideal fluid model.  It is not necessary to
      require that the specific order of packet departures match those
      of the fluid model since we presume that all detailed per-packet
      delay requirements of individual flows are addressed through
      quality of service commitments and, furthermore, the satisfaction
      with the link-sharing service delivered will probably not depend
      very sensitively on small deviations from the scheduling implied
      by the fluid link-sharing model.

      We previously observed that admission control was necessary to
      ensure that the real-time service commitments could be met.
      Similarly, admission control will again be necessary to ensure
      that the link-sharing commitments can be met.  For each entity,
      admission control must keep the cumulative guaranteed and
      predictive traffic from exceeding the assigned link-share.

   3.3 Packet Dropping

      So far, we have implicitly assumed that all packets within a flow
      were equally important.  However, in many audio and video streams,
      some packets are more valuable than others.  We therefore propose
      augmenting the service model with a "preemptable" packet service,
      whereby some of the packets within a flow could be marked as
      preemptable.  When the network was in danger of not meeting some
      of its quantitative service commitments, it could exercise a
      certain packet's "preemptability option" and discard the packet
      (not merely delay it, since that would introduce out-of-order
      problems).  By discarding these preemptable packets, a router can
      reduce the delays of the not-preempted packets.

      Furthermore, one can define a class of packets that is not subject
      to admission control.  In the scenario described above where
      preemptable packets are dropped only when quantitative service
      commitments are in danger of being violated, the expectation is
      that preemptable packets will almost always be delivered and thus
      they must included in the traffic description used in admission
      control.  However, we can extend preemptability to the extreme
      case of "expendable" packets (the term expendable is used to
      connote an extreme degree of preemptability), where the
      expectation is that many of these expendable packets may not be
      delivered.  One can then exclude expendable packets from the
      traffic description used in admission control; i.e., the packets



Braden, Clark & Shenker                                        [Page 18]

RFC 1633            Integrated Services Architecture           June 1994