rfc3148.txt

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

   of data (which would clearly require a retransmit timeout) TCP likely
   missed some opportunity to safely transmit data.  That is, if TCP
   experiences a timeout after losing a partial window of data, it must
   have received at least one ACK that was generated after some of the
   partial data was delivered, but did not trigger the transmission of
   new data.  Recent research in congestion control (e.g., FACK [MM96a],
   NewReno [FF96,RFC2582], rate-halving [MSML99]) can be characterized
   as making TCP's Self-Clock more tenacious, while preserving fairness
   under adverse conditions.  This work is motivated by how poorly
   current TCP implementations perform under some conditions, often due
   to repeated clock loss.  Since this is an active research area,
   different TCP implementations have rather considerable differences in
   their ability to preserve Self-Clock.

3.2 Preservation of Self-Clock

   Losing the ACK clock can have a large effect on the overall BTC, and
   the clock is itself fragile in ways that are dependent on the loss
   recovery algorithm.  Therefore, the transition between timer driven
   and Self-Clocked operation SHOULD be instrumented.

3.2.1 Lost Transmission Opportunities

   If the last event before a timeout was the receipt of an ACK that did
   not trigger a transmission, the possibility exists that an alternate
   congestion control algorithm would have successfully preserved the
   Self-Clock.  A BTC SHOULD instrument key items in the BTC state (such
   as the congestion window) in the hopes that this may lead to further
   improvements in congestion control algorithms.








Mathis, et al.               Informational                      [Page 6]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   Note that in the absence of knowledge about the future, it is not
   possible to design an algorithm that never misses transmission
   opportunities.  However, there are ever more subtle ways to gauge
   network state, and to estimate if a given ACK is likely to be the
   last.

3.2.2 Loosing an Entire Window

   If an entire window of data (or ACKs) is lost, there will be no
   returning ACKs to clock out additional data.  This condition can be
   detected if the last event before a timeout was a data transmission
   triggered by an ACK.  The loss of an entire window of data/ACKs
   forces recovery to be via a Retransmission Timeout and Slow-Start.

   Losing an entire window of data implies an outage with a duration at
   least as long as a round trip time.  Such an outage can not be
   diagnosed with low rate metrics and is unsafe to diagnose at higher
   rates than the BTC.  Therefore all BTC metrics SHOULD instrument and
   report losses of an entire window of data.

   Note that there are some conditions, such as when operating with a
   very small window, in which there is a significant probability that
   an entire window can be lost through individual random losses (again
   highlighting the importance of instrumenting cwnd).

3.2.3 Heroic Clock Preservation

   All algorithms that permit a given BTC to sustain Self-Clock when
   other algorithms might not, SHOULD be instrumented.  Furthermore, the
   details of the algorithms used MUST be fully documented (as discussed
   in section 2).

   BTC metrics that can sustain Self-Clock in the presence of multiple
   losses within one round trip SHOULD instrument the loss distribution,
   such that the performance of alternate congestion control algorithms
   may be estimated (e.g., Reno style).

3.2.4  False Timeouts

   All false timeouts, (where the retransmission timer expires before
   the ACK for some previously transmitted data arrives) SHOULD be
   instrumented when possible.  Note that depending upon how the BTC
   metric implements sequence numbers, this may be difficult to detect.








Mathis, et al.               Informational                      [Page 7]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


3.3 Ancillary Metrics Relating to Flow Based Path Properties

   All BTC metrics provide unique vantage points for observing certain
   path properties relating to closely spaced packets.  As in the case
   of RTT duration outages, these can be impossible to diagnose at low
   rates (less than 1 packet per RTT) and inappropriate to test at rates
   above the BTC of the network path.

   All BTC metrics SHOULD instrument packet reordering.  The frequency
   and distance out-of-sequence SHOULD be instrumented for all out-of-
   order packets.  The severity of the reordering can be classified as
   one of three different cases, each of which SHOULD be reported.

      Segments that are only slightly out-of-order should not trigger
      the fast retransmit algorithm, but they may affect the window
      calculation.  BTC metrics SHOULD document how slightly out-of-
      order segments affect the congestion window calculation.

      If segments are sufficiently out-of-order, the Fast Retransmit
      algorithm will be invoked in advance of the delayed packet's late
      arrival.  These events SHOULD be instrumented.  Even though the
      the late arriving packet will complete recovery, the the window
      will still be reduced by half.

      Under some rare conditions segments have been observed that are
      far out of order - sometimes many seconds late [Pax97b].  These
      SHOULD always be instrumented.

   BTC implementations SHOULD instrument the maximum cwnd observed
   during congestion avoidance and slow start.  A TCP running over the
   same path as the BTC metric must have sufficient sender buffer space
   and receiver window (and window shift [RFC1323]) to cover this cwnd
   in order to expect the same performance.

   There are several other path properties that one might measure within
   a BTC metric.  For example, with an embedded one-way delay metric it
   may be possible to measure how queuing delay and and (RED) drop
   probabilities are correlated to window size.  These are open research
   questions.

3.4 Ancillary Metrics as Calibration Checks

   Unlike low rate metrics, BTC SHOULD include explicit checks that the
   test platform is not the bottleneck.

   Any detected dropped packets within the sending host MUST be
   reported.  Unless the sending interface is the path bottleneck, any
   dropped packets probably indicates a measurement failure.



Mathis, et al.               Informational                      [Page 8]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   The maximum queue lengths within the sending host SHOULD be
   instrumented.  Any significant queue may indicate that the sending
   host has insufficient burst data rate, and is smoothing the data
   being transmitted into the network.

3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features

   If TCP would require advanced TCP extensions to match BTC performance
   (such as RFC 1323 or RFC 2018 features), it SHOULD be reported.

3.6 Validate Reverse Path Load

   To the extent possible, the BTC metric SHOULD distinguish between the
   properties of the forward and reverse paths.

   BTC methodologies which rely on non-cooperating receivers may only be
   able to measure round trip path properties and may not be able to
   independently differentiate between the properties of the forward and
   reverse paths.  In this case the load on the reverse path contributed
   by the BTC metric SHOULD be instrumented (or computed) to permit
   other means of gauge the proportion of the round trip path properties
   attributed to the the forward and reverse paths.

   To the extent possible, BTC methodologies that rely on cooperating
   receivers SHOULD support separate ancillary metrics for the forward
   and reverse paths.

4   Security Considerations

   Conducting Internet measurements raises security concerns.  This memo
   does not specify a particular implementation of a metric, so it does
   not directly affect the security of the Internet nor of applications
   which run on the Internet.  However, metrics produced within this
   framework, and in particular implementations of the metrics may
   create security issues.

4.1 Denial of Service Attacks

   Bulk Transport Capacity metrics, as defined in this document,
   naturally attempt to fill a bottleneck link.  The BTC metrics based
   on this specification will be as "network friendly" as current well-
   tuned TCP connections.  However, since the "connection" may not be
   using TCP packets, a BTC test may appear to network operators as a
   denial of service attack.







Mathis, et al.               Informational                      [Page 9]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   Administrators of the source host of a test, the destination host of
   a test, and the intervening network(s) may wish to establish
   bilateral or multi-lateral agreements regarding the timing, size, and
   frequency of collection of BTC metrics.

4.2 User data confidentiality

   Metrics within this framework generate packets for a sample, rather
   than taking samples based on user data.  Thus, a BTC metric does not
   threaten user data confidentiality.

4.3 Interference with metrics

   It may be possible to identify that a certain packet or stream of
   packets are part of a BTC metric.  With that knowledge at the
   destination and/or the intervening networks, it is possible to change
   the processing of the packets (e.g., increasing or decreasing delay,
   introducing or heroically preventing loss) that may distort the
   measured performance.  It may also be possible to generate additional
   packets that appear to be part of a BTC metric.  These additional
   packets are likely to perturb the results of the sample measurement.

   To discourage the kind of interference mentioned above, packet
   interference checks, such as cryptographic hash, may be used.

5   IANA Considerations

   Since this metric framework does not define a specific protocol, nor
   does it define any well-known values, there are no IANA
   considerations for this document.  However, a bulk transport capacity
   metric within this framework, and in particular protocols that
   implement a metric may have IANA considerations that need to be
   addressed.

6   Acknowledgments

   Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM working
   group for numerous clarifications.

   Matt Mathis's work was supported by the National Science Foundation
   under Grant Numbers 9415552 and 9870758.










Mathis, et al.               Informational                     [Page 10]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


7   References

   [BPS+97]     Hari Balakrishnan, Venkata Padmanabhan, Srinivasan
                Seshan, Mark Stemm, and Randy Katz.  TCP Behavior of a
                Busy Web Server:  Analysis and Improvements.  Technical
                Report UCB/CSD-97-966, August 1997.  Available from
                http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps.
                (Also in Proc. IEEE INFOCOM Conf., San Francisco, CA,
                March 1998.)

   [FF96]       Fall, K., Floyd, S..  "Simulation-based Comparisons of
                Tahoe, Reno and SACK TCP".  Computer Communication
                Review, July 1996.
                ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.

   [Flo95]      Floyd, S., "TCP and successive fast retransmits", March
                1995, Obtain via
                ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.

   [Hoe96]      Hoe, J., "Improving the start-up behavior of a
                congestion control scheme for TCP, Proceedings of ACM
                SIGCOMM '96, August 1996.

   [Hoe95]      Hoe, J., "Startup dynamics of TCP's congestion control
                and avoidance schemes".  Master's thesis, Massachusetts
                Institute of Technology, June 1995.

   [Jac88]      Jacobson, V., "Congestion Avoidance and Control",
                Proceedings of SIGCOMM '88, Stanford, CA., August 1988.

   [Lak94]      V. T. Lakshman and U. Madhow. The Performance of TCP/IP
                for Networks with High Bandwidth-Delay Products and
                Random Loss. IFIP Transactions C-26, High Performance
                Networking, pages 135--150, 1994.