rfc2859.txt

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

   - If the estimated average rate is greater than the PTR,
     packets are designated red with probability P1, designated
     yellow with probability P2 and designated green with probability
     (1-(P1+P2)). P1 is the fraction of packets contributing
     to the measured rate beyond the PTR. P2 is the fraction of
     packets contributing to that part of the measured rate
     between CTR and PTR.

     The marker MUST operate in the forwarding path of all packets.

5.0 Configuration

5.1 Rate estimator

   If the Rate Estimator is time-based, it should base its bandwidth
   estimate on the last AVG_INTERVAL of time.  AVG_INTERVAL is the
   amount of history (recent time) that should be used by the algorithm
   in estimating the rate. Essentially it represents the window of time
   included in the Rate Estimator's most recent result.

   The value of AVG_INTERVAL SHOULD be configurable, and MAY be
   specified in either milliseconds or seconds.




Fang, et al.                  Experimental                      [Page 5]

RFC 2859                         TSWTCM                        June 2000


   [TON98] recommends that for the case where a single TCP flow
   constitutes the contracted traffic, AVG_INTERVAL be configured to
   approximately the same value as the RTT of the TCP flow.  Subsequent
   experimental studies in [GLOBE99] utilized an AVG_INTERVAL value of 1
   second for scenarios where the contracted traffic consisted of
   multiple TCP flows, some with different RTT values. The latter work
   showed that AVG_INTERVAL values larger than the largest RTT for a TCP
   flow in an aggregate can be used as long as the long-term bandwidth
   assurance for TCP aggregates is measured at a granularity of seconds.
   The AVG_INTERVAL value of 1 second was also used successfully for
   aggregates with UDP flows.

   If the Rate Estimator is weight-based, the factor used in weighting
   history - WEIGHT - SHOULD be a configurable parameter.

   The Rate Estimator measures the average sending rate of the traffic
   stream based on the bytes in the IP header and IP payload. It does
   not include link-specific headers in its estimation of the sending
   rate.

5.2 Marker

   The TSWTCM marker is configured by assigning values to its two
   traffic parameters: Committed Target Rate (CTR) and Peak Target Rate
   (PTR).

   The PTR MUST be equal to or greater than the CTR.

   The CTR and PTR MAY be specifiable in bits per second or bytes per
   second.

   The TSWTCM can be configured so that it essentially operates with a
   single rate. If the PTR is set to the same value as the CTR then all
   packets will be coloured either green or red. There will be no yellow
   packets.

   If the PTR is set to link speed and the CTR is set below the PTR then
   all packets will be coloured either green or yellow. There will be no
   red packets.

6.0 Scaling properties

   The TSWTCM can work with both sender-based service level agreements
   and receiver-based service level agreements.







Fang, et al.                  Experimental                      [Page 6]

RFC 2859                         TSWTCM                        June 2000


7.0 Services

   There are no restrictions on the type of traffic stream for which the
   TSWTCM can be utilized. It can be used to meter and mark individual
   TCP flows, aggregated TCP flows, aggregates with both TCP and UDP
   flows [UDPTCP] etc.

   The TSWTCM can be used in conjunction with the AF PHB to create a
   service where a service provider can provide decreasing levels of
   bandwidth assurance for packets originating from customer sites.

   With sufficient over-provisioning, customers are assured of mostly
   achieving their CTR.  Sending rates beyond the CTR will have lesser
   assurance of being achieved. Sending rates beyond the PTR have the
   least chance of being achieved due to high drop probability of red
   packets.

   Based on the above, the Service Provider can charge a tiered level of
   service based on the final achieved rate.

8.0 Security Considerations

   TSWTCM has no known security concerns.

9.0 Acknowledgements

   The authors would like to thank Juha Heinanen, Kenjiro Cho, Ikjun
   Yeom and Jamal Hadi Salim for their comments on earlier versions of
   this document. Their suggestions are incorporated in this memo.

10.0 References

   [TON98]   D.D. Clark, W. Fang, "Explicit Allocation of Best Effort
             Packet Delivery Service", IEEE/ACM Transactions on
             Networking, August 1998, Vol 6. No. 4, pp. 362-373.

   [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
             of the Differentiated  Services Field (DS Field) in the
             IPv4 and IPv6 Headers", RFC 2474, December 1998.

   [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and
             W. Weiss, "An Architecture for Differentiated Services",
             RFC 2475, December 1998.

   [FANG99]  Fang, W. "The 'Expected Capacity' Framework: Simulation
             Results", Princeton University Technical Report, TR-601-99,
             March, 1999.




Fang, et al.                  Experimental                      [Page 7]

RFC 2859                         TSWTCM                        June 2000


   [YEOM99]  I. Yeom, N. Reddy, "Impact of Marking Strategy on
             Aggregated Flows in a Differentiated Services Network",
             Proceedings of IwQoS, May 1999.

   [AFPHB]   Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
             "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [UDPTCP]  P. Pieda, N. Seddigh, B. Nandy, "The Dynamics of TCP and
             UDP Interaction in IP-QoS Differentiated Service Networks",
             Proceedings of the 3rd Canadian Conference on Broadband
             Research (CCBR), Ottawa, November 1999

   [GLOBE99] N. Seddigh, B. Nandy, P. Pieda, "Bandwidth Assurance Issues
             for TCP flows in a Differentiated Services Network",
             Proceedings of Global Internet Symposium, Globecom 99, Rio
             De Janeiro, December 1999.

11.0 Authors' Addresses

   Wenjia Fang
   Computer Science Dept.
   35 Olden Street,
   Princeton, NJ08540

   EMail: [e-mail]


   Nabil Seddigh
   Nortel Networks,
   3500 Carling Ave
   Ottawa, ON, K2H 8E9
   Canada

   EMail: [e-mail]


   Biswajit Nandy
   Nortel Networks,
   3500 Carling Ave
   Ottawa, ON, K2H 8E9
   Canada

   EMail: [e-mail]








Fang, et al.                  Experimental                      [Page 8]

RFC 2859                         TSWTCM                        June 2000


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Fang, et al.                  Experimental                      [Page 9]