rfc3357.txt

RFC 的详细文档！

      there are 3 loss distances that violate the delta of 2.  Thus,
      Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable
      losses)/(number of total losses))

   -  In Type-P-One-Way-Loss-Period-Stream

         {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},

      the largest of the first entry in the sequence of <loss
      period,loss> pairs is 4.  Thus,

      Type-P-One-Way-Loss-Period-Total = 4

   -  In Type-P-One-Way-Loss-Period-Stream

         {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},

      the lengths of individual loss periods are 1, 1, 1 and 2
      respectively.  Thus,

      Type-P-One-Way-Loss-Period-Lengths =

         {<1,1>,<2,1>,<3,1>,<4,2>}

   -  In Type-P-One-Way-Loss-Period-Stream

         {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},

      the loss periods 1 and 2 are separated by 3 (5-2), loss periods 2
      and 3 are separated by 2 (7-5), and 3 and 4 are separated by 2
      (9-7).  Thus, Type-P-One-Way-Inter-Loss-Period-Lengths =

         {<1,0>,<2,3>,<3,2>,<4,2>}

7. Security Considerations

   Conducting Internet measurements raises both security and privacy
   concerns.  This document does not specify a particular implementation
   of metrics, so it does not directly affect the security of the
   Internet nor of applications which run on the Internet.  However,
   implementations of these metrics must be mindful of security and
   privacy concerns.

   The derived sample metrics in this document are based on the loss
   metric defined in RFC 2680 [1], and thus they inherit the security
   considerations of that document.  The reader should consult [1] for a
   more detailed treatment of security considerations.  Nevertheless,
   there are a few things to highlight.



Koodli & Ravikanth           Informational                     [Page 11]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002


7.1. Denial of Service Attacks

   The lambda specified in the Type-P-Loss-Distance-Stream and Type-P-
   Loss-Period-Stream controls the rate at which test packets are sent,
   and therefore if it is set inappropriately large, it could perturb
   the network under test, cause congestion, or at worst be a denial-
   of-service attack to the network under test.  Legitimate measurements
   must have their parameters selected carefully in order to avoid
   interfering with normal traffic in the network.

7.2. Privacy / Confidentiality

   Privacy of user data is not a concern, since the underlying metric is
   intended to be implemented using test packets that contain no user
   information.  Even if packets contained user information, the derived
   metrics do not release data sent by the user.

7.3. Integrity

   Results could be perturbed by attempting to corrupt or disrupt the
   underlying stream, for example adding extra packets that look just
   like test packets.  To ensure that test packets are valid and have
   not been altered during transit, packet authentication and integrity
   checks, such as a signed cryptographic hash, MAY be used.

8. IANA Considerations

   Since this document does not define a specific protocol, nor does it
   define any well-known values, there are no IANA considerations for
   this document.

9. Acknowledgements

   Matt Zekauskas provided insightful feedback and the text for the
   Security Considerations section.  Merike Kao helped revising the
   Security Considerations and the Abstract to conform with RFC
   guidelines.  We thank both of them.  Thanks to Guy Almes for
   encouraging the work, and Vern Paxson for the comments during the
   IETF meetings.  Thanks to Steve Glass for making the presentation at
   the Oslo meeting.

10. Normative References

   [1]  Almes, G., Kalindindi, S. and M. Zekauskas, "A One-way Packet
        Loss Metric for IPPM", RFC 2680, September 1999.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.



Koodli & Ravikanth           Informational                     [Page 12]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002


   [3]  Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
        IP Performance Metrics", RFC 2330, May 1998.

11. Informative References

   [4]  J.-C. Bolot and A. vega Garcia, "The case for FEC-based error
        control for Packet Audio in the Internet", ACM Multimedia
        Systems, 1997.

   [5]  M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster,
        "Internet Packet Loss:  Measurement and Implications for End-
        to-End QoS," Proceedings, International Conference on Parallel
        Processing, August 1998.

   [6]  M. Handley, "An examination of MBONE performance", Technical
        Report, USC/ISI, ISI/RR-97-450, July 1997

   [7]  R. Koodli, "Scheduling Support for Multi-tier Quality of Service
        in Continuous Media Applications", PhD dissertation, Electrical
        and Computer Engineering Department, University of
        Massachusetts, Amherst, MA 01003, September 1997.

   [8]  J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP
        throughput:  a simple model and its empirical validation", in
        Proceedings of SIGCOMM'98, 1998.

   [9]  J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly
        rate adjustment protocol for continuous media flows over best-
        effort networks", short paper presentation in ACM SIGMETRICS'99.
        Available as Umass Computer Science tech report from
        ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz

   [10] K. Sriram and W. Whitt, "Characterizing superposition arrival
        processes in packet multiplexers for voice and data", IEEE
        Journal on Selected Areas of Communication, pages 833-846,
        September 1986,

   [11] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation in
        the MBONE multicast network", Proceedings of IEEE Global
        Internet, London, UK, November 1996.











Koodli & Ravikanth           Informational                     [Page 13]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002


Authors' Addresses

   Rajeev Koodli
   Communications Systems Lab
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

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


   Rayadurgam Ravikanth
   Axiowave Networks Inc.
   200 Nickerson Road
   Marlborough, MA 01752
   USA

   EMail: [e-mail]






























Koodli & Ravikanth           Informational                     [Page 14]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Koodli & Ravikanth           Informational                     [Page 15]