rfc2975.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   effects of packet loss.

   UDP-based transport is frequently used in accounting applications.
   However, this is not appropriate in all cases.  Where accounting data
   will not fit within a single UDP packet without fragmentation, use of
   TCP or SCTP transport may be preferred to use of multiple round-trips
   in UDP.  As noted in [47] and [49], this may be an issue in the
   retrieval of large tables.

   In addition, in cases where congestion is likely, such as in inter-
   domain accounting, TCP or SCTP congestion control and round-trip time
   estimation will be very useful, optimizing throughput.  In
   applications which require maintenance of session state, such as
   simultaneous usage control, TCP and application-layer keep alive
   packets or SCTP with its built-in heartbeat capabilities provide a
   mechanism for keeping track of session state.

   When implementing UDP retransmission, there are a number of issues to
   keep in mind:

      Data model
      Retry behavior
      Congestion control
      Timeout behavior

   Accounting reliability can be influenced by how the data is modeled.
   For example, it is almost always preferable to use cumulative
   variables rather than expressing accounting data in terms of a change
   from a previous data item.  With cumulative data, the current state
   can be recovered by a successful retrieval, even after many packets
   have been lost.  However, if the data is transmitted as a change then
   the state will not be recovered until the next cumulative update is
   sent.  Thus, such implementations are much more vulnerable to packet
   loss, and should be avoided wherever possible.

   In designing a UDP retry mechanism, it is important that the retry
   timers relate to the round-trip time, so that retransmissions will
   not typically occur within the period in which acknowledgments may be
   expected to arrive.  Accounting bandwidth may be significant in some
   circumstances, so that the added traffic due to unnecessary
   retransmissions may increase congestion levels.






Aboba, et al.                Informational                     [Page 17]

RFC 2975         Introduction to Accounting Management      October 2000


   Congestion control in accounting data transfer is a somewhat
   controversial issue.  Since accounting traffic is often considered
   mission-critical, it has been argued that congestion control is not a
   requirement; better to let other less-critical traffic back off in
   response to congestion.  Moreover, without non-volatile storage,
   congestive back-off in accounting applications can result in data
   loss due to buffer exhaustion.

   However, it can also be argued that in modern accounting
   implementations, it is possible to implement congestion control while
   improving throughput and maintaining high reliability.  In
   circumstances where there is sustained packet loss, there simply is
   not sufficient capacity to maintain existing transmission rates.
   Thus, aggregate throughput will actually improve if congestive back-
   off is implemented.  This is due to elimination of retransmissions
   and the ability to utilize techniques such as RED to desynchronize
   flows.  In addition, with QoS mechanisms such as differentiated
   services, it is possible to mark accounting packets for preferential
   handling so as to provide for lower packet loss if desired.  Thus
   considerable leeway is available to the network administrator in
   controlling the treatment of accounting packets and hard coding
   inelastic behavior is unnecessary.  Typically, systems implementing
   non-volatile storage allow for backlogged accounting data to be
   placed in non-volatile storage pending transmission, so that buffer
   exhaustion resulting from congestive back-off need not be a concern.

   Since UDP is not really a transport protocol, UDP-based accounting
   protocols such as [4] often do not prescribe timeout behavior.  Thus
   implementations may exhibit widely different behavior.  For example,
   one implementation may drop accounting data after three constant
   duration retries to the same server, while another may implement
   exponential back-off to a given server, then switch to another
   server, up to a total timeout interval of twelve hours, while storing
   the untransmitted data on non-volatile storage.  The practical
   difference between these approaches is substantial; the former
   approach will not satisfy archival accounting requirements while the
   latter may.  More predictable behavior can be achieved via use of
   SCTP or TCP transport.

2.1.4.  Accounting server failover

   In the event of a failure of the primary accounting server, it is
   desirable for the device to failover to a secondary server.
   Providing one or more secondary servers can remove much of the risk
   of accounting server failure, and as a result use of secondary
   servers has become commonplace.





Aboba, et al.                Informational                     [Page 18]

RFC 2975         Introduction to Accounting Management      October 2000


   For protocols based on TCP, it is possible for the device to maintain
   connections to both the primary and secondary accounting servers,
   using the secondary connection after expiration of a timer on the
   primary connection.  Alternatively,  it is possible to open a
   connection to the secondary accounting server after a timeout or loss
   of the primary connection, or on  expiration of a timer.  Thus,
   accounting protocols based on TCP are capable of responding more
   rapidly to connectivity failures than TCP timeouts would otherwise
   allow, at the expense of an increased risk of duplicates.

   With SCTP, it is possible to control transport layer timeout
   behavior, and therefore it is not necessary for the accounting
   application to maintain its own timers.  SCTP also enables
   multiplexing of multiple connections within a single transport
   connection, all maintaining the same congestion control state,
   avoiding the "head of line blocking" issues that can occur with TCP.
   However, since SCTP is not widely available, use of this transport
   can impose an additional implementation burden on the designer.

   For protocols using UDP, transmission to the secondary  server can
   occur after a number of retries or timer expiration.  For
   compatibility with congestion avoidance, it is advisable to
   incorporate techniques such as round-trip-time estimation, slow start
   and congestive back-off.  Thus the accounting protocol designer
   utilizing UDP often is lead to re-inventing techniques already
   existing in TCP and SCTP.  As a result, the use of raw UDP transport
   in accounting applications is not recommended.

   With any transport it is possible for the primary and secondary
   accounting servers to receive duplicate packets, so support for
   duplicate elimination is required.  Since accounting server failures
   can result in data accumulation on accounting clients, use of non-
   volatile storage can ensure against data loss due to transmission
   timeouts or buffer exhaustion.  On-the-wire interim accounting
   provides only limited benefits in mitigating the effects of
   accounting server failures.

2.1.5.  Application layer acknowledgments

   It is possible for the accounting server to experience partial
   failures.  For example, a failure in the database back end could
   leave the accounting retrieval process or thread operable while the
   process or thread responsible for storing the data is non-functional.
   Similarly, it is possible for the accounting application to run out
   of disk space, making it unable to continue storing incoming session
   records.





Aboba, et al.                Informational                     [Page 19]

RFC 2975         Introduction to Accounting Management      October 2000


   In such cases it is desirable to distinguish between transport layer
   acknowledgment and application layer acknowledgment.  Even though
   both acknowledgments may be sent within the same packet (such as a
   TCP segment carrying an application layer acknowledgment along with a
   piggy-backed ACK), the semantics are different.  A transport-layer
   acknowledgment means "the transport layer has taken responsibility
   for delivering the data to the application", while an application-
   layer acknowledgment means "the application has taken responsibility
   for the data".

   A common misconception is that use of TCP transport guarantees that
   data is delivered to the application.  However, as noted in RFC 793
   [7]:

    An acknowledgment by TCP does not guarantee that the data has been
    delivered to the end user, but only that the receiving TCP has taken
    the responsibility to do so.

   Therefore, if receiving TCP fails after sending the ACK, the
   application may not receive the data.  Similarly, if the application
   fails prior to committing the data to stable storage, the data may be
   lost.  In order for a sending application to be sure that the data it
   sent was received by the receiving application, either a graceful
   close of the TCP connection or an application-layer acknowledgment is
   required. In order to protect against data loss, it is necessary that
   the application-layer acknowledgment imply that the data has been
   written to stable storage or suitably processed so as to guard
   against loss.

   In the case of partial failures, it is possible for the transport
   layer to acknowledge receipt via transport layer acknowledgment,
   without having delivered the data to the application.  Similarly, the
   application may not complete the tasks necessary to take
   responsibility for the data.

   For example, an accounting server may receive data from the transport
   layer but be incapable of storing it data due to a back end database
   problem or disk fault.  In this case it should not send an
   application layer acknowledgment, even though a a transport layer
   acknowledgment is appropriate.  Rather, an application layer error
   message should be sent indicating the source of the problem, such as
   "Backend store unavailable".

   Thus application-layer acknowledgment capability requires not only
   the ability to acknowledge when the application has taken
   responsibility for the data, but also the ability to indicate when
   the application has not taken responsibility for the data, and why.




Aboba, et al.                Informational                     [Page 20]

RFC 2975         Introduction to Accounting Management      October 2000


2.1.6.  Network failures

   Network failures may result in partial or complete loss of
   connectivity for the accounting client.  In the event of partial
   connectivity loss, it may not be possible to reach the primary
   accounting server, in which case switch over to the secondary
   accounting server is necessary.  In the event of a network partition,
   it may be necessary to store accounting events in device memory or
   non-volatile storage until connectivity can be re-established.

   As with accounting server failures, on-the-wire interim accounting
   provides only limited benefits in mitigating the effects of network
   failures.

2.1.7.  Device reboots

   In the event of a device reboot, it is desirable to minimize the loss
   of data on sessions in progress.  Such losses may be significant even
   if the devices themselves are very reliable, due to long-lived
   sessions, which can comprise a significant fraction of total resource
   consumption.  To guard against loss of these high-value sessions,
   interim accounting data is typically transmitted over the wire.  When
   interim accounting in-place is combined with non-volatile storage it
   becomes possible to guard against data loss in much shorter sessions.
   This is possible since interim accounting data need only be stored in
   non-volatile memory until the session completes, at which time the
   interim data may be replaced by the session record.  As a result,
   interim accounting data need never be sent over the wire, and it is
   possible to decrease the interim interval so as to provide a very
   high degree of protection against data loss.

2.1.8.  Accounting proxies

   In order to maintain high reliability, it is important that
   accounting proxies pass through transport and application layer
   acknowledgments and do not store and forward accounting packets.
   This enables the end-systems to control re-transmission behavior and
   utilize techniques such as non-volatile storage and secondary servers
   to improve resilience.

   Accounting proxies sending a transport or application layer ACK to
   the device without receiving one from the accounting server fool the
   device into thinking that the accounting request had been accepted by
   the accounting server when this is not the case.  As a result, the
   device can delete the accounting packet from non-volatile storage
   before it has been accepted by the accounting server.  The leaves the





Aboba, et al.                Informational                     [Page 21]

RFC 2975         Introduction to Accounting Management      October 2000


   accounting proxy responsible for delivering accounting packets.  If
   the accounting proxy involves moving parts (e.g. a disk drive) while
   the devices do not, overall system reliability can be reduced.

   Store and forward accounting proxies only add value in situations
   where the accounting subsystem is unreliable.  For example, where
   devices do not implement non-volatile storage and the accounting
   protocol lacks transport and application layer reliability, locating
   the accounting proxy (with its stable storage) close to the device
   can reduce the risk of data loss.

   However, such systems are inherently unreliable so that they are only
   appropriate for use in capacity planning or non-usage sensitive
   billing applications.  If archival accounting reliability is desired,
   it is necessary to engineer a reliable accounting system from the
   start using the techniques described in this document, rather than
   attempting to patch an inherently unreliable system by adding store
   and forward accounting proxies.