[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         Y. Kikuchi
Internet-Draft                            Kochi University of Technology
Intended status: Standards Track                           S. Matsushima
Expires: November 22, 2008                        Softbank Telecom Corp.
                                                               K. Nagami
                                                      Intec Netcore Inc.
                                                                  S. Uda
                                             Japan Advanced Institute of
                                                  Science and Technology
                                                             N. Ogashiwa
                                           Maebashi Kyoai Gakuen College
                                                            May 21, 2008


           One-way Passive Measurement of End-to-End Quality
                  draft-kikuchi-passive-measure-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 22, 2008.










Kikuchi, et al.         Expires November 22, 2008               [Page 1]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


Abstract

   This draft describes a passive measurement method for one-way end-to-
   end quality.  This method reports both whether a flow of packets is
   in-sequence or not and error types on detecting out-of-sequence.  The
   method consumes small resource therefore it can be adapted to many
   protocols that have sequence number field.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3

   2.  Metrics  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Measurement Method . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Counters and Functions . . . . . . . . . . . . . . . . . .  5
     3.2.  Measurement Algorithm  . . . . . . . . . . . . . . . . . .  5

   4.  Requirements to Sequence Numbering . . . . . . . . . . . . . .  7
     4.1.  Indication of Sequence Number  . . . . . . . . . . . . . .  7
     4.2.  Field Length . . . . . . . . . . . . . . . . . . . . . . .  7

   5.  An Evaluation Trial  . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Usefullness  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Qualifying Metrics . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Reporting Model  . . . . . . . . . . . . . . . . . . . . .  9

   6.  Algorithm Behavior . . . . . . . . . . . . . . . . . . . . . . 10

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15

   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 16

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19










Kikuchi, et al.         Expires November 22, 2008               [Page 2]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


1.  Introduction

   This draft describes a passive measurement method for one-way end-to-
   end connections quality.  This method reports both

   o  whether a flow of packets is in-sequence or out-of-sequence, and

   o  error types on detecting out-of-sequence.

   The purpose of the measurement by this method is to maintain
   transports in operation [I-D.kikuchi-tunnel-measure-req] so that the
   algorithm was designed to be lightweight.  The algorithm detects out-
   of-sequence packets strictly though; the error metrics is even not
   accurate because the metrics should only provide some hints to
   operators.

   The algorithm requires a sequence number field in the packet headers,
   such as extended GRE[RFC2784] [RFC2890], PWE3[RFC3985] and
   RTP[RFC3550].

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


























Kikuchi, et al.         Expires November 22, 2008               [Page 3]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


2.  Metrics

   We firstly define ``in-sequence'' of a flow.

   o  in-sequence: the order of arrival packets at the egress of a flow
      is the same order as departure at the ingress.

   o  out-of-sequence: a packet exists, which violates in-sequence state
      of a flow.

   We secondly define the metrics of types of out-of-sequence packet.

   o  dup-train: packet that is identical to the immediately preceding
      arrival packet

   o  skipping: packet that should arrive next or more lately

   o  astern: packet that arrives after the successive packets' arrival

   The metrics ``dup-train'', ``skipping'' and ``astern'' are similar to
   duplication, lost and reordering respectively though, these metrics
   above have different names because the definitions are slightly
   different from any metrics defined before.

   o  ``dup-train'' does not mean naive duplication because the pair of
      dup-train packets should arrive uninterruptedly by another packet.

   o  ``skipping'' happens on ``packet loss'' and even by
      ``reordering''.

   o  ``astern'' might count inaccrately for as reordering packets on
      complicated situation.

   This kind of difference comes from the request of let the algorithm
   lightweight described in Section 3.  An accurate algorithm must have
   much space for keeping the order of arrival packets until the exact
   irregular reason will be become clear, moreover it takes much
   computing power according to the space consumption.  Those rough
   metrics above allow to shrink the space that keeps just one sequence
   number of the previously arrival packet.

   Note that we do not define some kinds of ``rates'' because they are
   easy to derived from total numbers of irregular packets.  For
   example, if you use SNMP [RFC3411] the rates are calculated from
   periodical polling by an SNMP manager.






Kikuchi, et al.         Expires November 22, 2008               [Page 4]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


3.  Measurement Method

   In this section, we illustrate a method to measure qualities defined
   in the previous section.  The protocol should have the sequence
   number field in its headers.

3.1.  Counters and Functions

   Egress router of a flow must have a register, named ``recvseq'', that
   maintains the number that the successive arriving packet should have.
   The ``recvseq'' register should be initialized by the specific number
   depends on the target protocol.

   The router must also have the following counters:

   o  duptrcnt: the number of dup-train packets,

   o  skipcnt: the number of skipping packets, and

   o  astrncnt: the number of astern packets

   Let the counters above be unsigned integer and initialized by 0 on
   the birth of the flow.  The length of the counters should be the same
   as the sequence number field defined in the protocol.

3.2.  Measurement Algorithm

   This algorithm determines whether a receiving packet is normal or not
   while comparing a counter "recvseq" with the sequence number of the
   packet named "seqno".  The basic idea consists of the following
   conditions.

   1.  if recvseq and seqno are same then "in-sequence",

   2.  else if seqno is just a predecessor of recvseq then "dup-train";

   3.  otherwise if seqno proceed then "skipping" else "astern".

   The following C-like codes specifies the algorithm in detail.  The
   function measure will be invoked by every one of the receptions of
   packets.










Kikuchi, et al.         Expires November 22, 2008               [Page 5]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


   boolean measure(packet_t packet)
   {
           unsigned int seqno;
           seqno = packet->header->seqno;  // getting seq # from header

           if (seqno == recvseq) {
                   recvseq++;
                   return true;            // in-sequence
           } elsif (seqno+1 == recvseq) {  // same # as predecessor's
                   duptrcnt++;             // determines a dup-train
                   return false;           // out-of-seq by dup-train
           }

           signed int diff;
           diff = (signed int)(seqno - recvseq);
           if (diff > 0) {                 // from past or future?
                   skipcnt += diff;        // determines a skipping
                   recvseq = seqno;
           } else {                        // means it is a past packet
                   astrncnt++;             // determines a astern
           }
           return false;                   // out-of-seq w/o dup-train
   }

                                 Figure 1

   The function ``measure'' returns true only if the packet is in-
   sequence otherwise false on out-of-sequence.  The value can be used
   to discard the packet when the protocol does not allow passing
   irregular packets to its higher layer.





















Kikuchi, et al.         Expires November 22, 2008               [Page 6]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


4.  Requirements to Sequence Numbering

   In this section, we describe the requirements for protocols to adopt
   this method.

4.1.  Indication of Sequence Number

   The protocol MUST indicate whether sequence numbering is enabled or
   not.

   There are two ways to indicate whether the sequence numbers are
   enabled or not.  One is to prepare an indication field in the header
   independent from the sequence number field.

   The other is to indicate a special sequence number, typically 0,
   meaning disabled.  In this case, the measurement process needs
   additional steps on wrapping sequence number overflow because the
   sequence number will skip 0 that does not seem continuous even if the
   flow packets are still in-sequence.

4.2.  Field Length

   The length of sequence number field SHOULD be long enough according
   to the transmission speed.  Otherwise, the period of a lap of the
   sequence number becomes too short and the reliability of the
   measurement decreases.

   For example, the algorithm may determine packets loss as reordering,
   when there is a set of burst packets loss in case of the path change.
   It is necessary to determine whether a burst packet loss occurred or
   if it was simply the arrival of a very past packet when the
   difference of the sequence numbers between two continuous packets is
   very large.  The typical technique is to use half of the
   representable maximum value.  This is simple and adequate if the
   field is long enough.

   However, the existence of the sequence number field generates more
   amounts of transmission packets.  Thus, if an insufficiently long
   field creates overhead for protocols that are sensitive to resource
   consumption.  The sequence number field length should be considered
   as a tradeoff between bandwidth efficiency and quality assurance.










Kikuchi, et al.         Expires November 22, 2008               [Page 7]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


5.  An Evaluation Trial

   Here we try to evaluate the metrics according to the framework
   described in [I-D.morton-perf-metrics-framework].

5.1.  Usefullness

   Firstly, we check the usefullness of the metrics listed in the
   section 3.1 of [I-D.morton-perf-metrics-framework].

   1.  The degree to which its absence would cause significant loss of
       information on the behavior or state of the application or system
       being measured?

       *  YES for TSPs who have SLA contracts with their customers.

       *  NO for best effort oriented flows.

   2.  The correlation between the metric and the quality of service /
       experience delivered to the user (person or other application)?

       *  YES.  It shows primitive quality to determine a flow traffic
          in operation.

       *  NO.  There is no correlation to any application because the
          metrics are independent from specific applications.

   3.  The degree to which the metric is able to support the
       identification and location of problems affecting service
       quality?

       *  YES.  It helps for operators to find out that problems come
          from whether application or transport.

       *  NO.  It does not indicate that problems come from whether TSP
          or intermediate ISPs.

5.2.  Qualifying Metrics

   Secondly, we qualify the metrics by the list in the section 3.5 of
   [I-D.morton-perf-metrics-framework].

   o  Unambiguously defined?  Yes. The description is not by a concrete
      specification in natural language but in C-code.

   o  Units of Measure Specified?  Yes.





Kikuchi, et al.         Expires November 22, 2008               [Page 8]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


   o  Measurement Errors Identified?  Refer to Section 4.2 for less
      sequence field length.

   o  Repeatable?  Yes.

   o  Implementable?  Yes, very much.

   o  Assumptions concerning underlying process?  Not discussed.

   o  Use cases?  Yes. Some examples are shown in Section 6.  Moreover,
      there is an implementation using the metrics in a multi-homing
      solution with [RFC4908], which has been provided by Intec Netcore
      Inc.

   o  Correlation with application performance / user experience?  The
      discussion is done in Section 5.1.

5.3.  Reporting Model

   The document does not define any reporting model for the metric.































Kikuchi, et al.         Expires November 22, 2008               [Page 9]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


6.  Algorithm Behavior

   The following diagrams show the behavior of the algorithm on
   receiving out-of-sequence packets.  Figure 3 shows the legend of flow
   diagram here.  The left and right sides represent the sender and
   receiver of a flow respectively.  Time flows upper to lower in the
   diagrams.  This illustrates a normal transmission with the sequence
   number n.

     time           sender              receiver

       |              |                    |
       |           n  |                    |  n   0 0 0
       |              |----[seq #: n]----->|
       |          n+1 |                    | n+1  0 0 0
       |              |                    |
       V              V                    V

                                 Figure 2

   Figure 3, Figure 4 and Figure 5 show simple cases, such as loss,
   duplication and reordering of packets respectively.





























Kikuchi, et al.         Expires November 22, 2008              [Page 10]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


                           [astrncnt]................
                           [duptrcnt].............. :
                            [skipcnt]............ : :
                                                : : :
                            [recvseq].........  : : :
                    ........[sendseq]        :  : : :
                    :                        :  : : :
                    :                        :  : : :
                    :                        :  : : :
                      |                    |
                    0 |                    | 0  0 0 0
                      |------------------->|
                    1 |                    | 1  0 0 0
                      |------------------->|
                    2 |                    | 2  0 0 0
                      |-----> !LOST!       |
                    3 |                    |
                      |------------------->|
                    4 |                    | 4  1 0 0
                      |-----> !LOST!       |
                    5 |                    |
                      |-----> !LOST!       |
                    6 |                    |
                      |------------------->|
                    7 |                    | 7  3 0 0
                      |                    |
                      V                    V

                                 Figure 3






















Kikuchi, et al.         Expires November 22, 2008              [Page 11]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


                           [astrncnt]................
                           [duptrcnt].............. :
                            [skipcnt]............ : :
                                                : : :
                            [recvseq].........  : : :
                    ........[sendseq]        :  : : :
                    :                        :  : : :
                      |                    |
                    0 |                    | 0  0 0 0
                      |------------------->|
                    1 |                    | 1  0 0 0
                      |-------!DUP!------->|
                      |         \          | 2  0 0 0
                      |          \-------->|
                    2 |                    | 2  0 1 0
                      |------------------->|
                    3 |                    | 3  0 1 0
                      |-------!DUP!------->|
                    4 |         \          | 4  0 1 0
                      |        !DUP!------>|
                      |           \        | 4  1 2 0
                      |            \------>|
                      |                    | 4  1 3 0
                      |------------------->|
                    5 |                    | 5  1 3 0
                      |                    |
                      V                    V

                                 Figure 4






















Kikuchi, et al.         Expires November 22, 2008              [Page 12]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


                           [astrncnt]................
                           [duptrcnt].............. :
                            [skipcnt]............ : :
                                                : : :
                            [recvseq].........  : : :
                    ........[sendseq]        :  : : :
                    :                        :  : : :
                      |                    |
                    0 |                    | 0  0 0 0
                      |------------------->|
                    1 |                    | 1  0 0 0
                      |-------\            |
                    2 |        \           |
                      |---------\--------->|
                    3 |          \         | 3  1 0 0
                      |           \------->|
                      |                    | 3  1 0 1
                      |------------------->|
                    4 |                    | 4  1 0 1
                      |-------\            |
                    5 |        \           |
                      |------\  \          |
                    6 |       \  \         |
                      |--------\--\------->|
                    7 |         \  \       | 7  3 0 1
                      |          \  \----->|
                      |           \        | 7  3 0 2
                      |            \------>|
                      |                    | 7  3 0 3
                      |                    |
                      V                    V

                                 Figure 5

   Figure 6 and Figure 7 show cases in a little bit complex situations.
   Figure 6 shows that the algorithm cannot distinguish a combination of
   duplication and loss from a reordering.  Compare the flow to former
   of Figure 5.













Kikuchi, et al.         Expires November 22, 2008              [Page 13]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


                           [astrncnt]................
                           [duptrcnt].............. :
                            [skipcnt]............ : :
                                                : : :
                            [recvseq].........  : : :
                    ........[sendseq]        :  : : :
                    :                        :  : : :
                      |                    |
                    0 |                    | 0  0 0 0
                      |------------------->|
                    1 |                    | 1  0 0 0
                      |-----!DUP!-->!LOST! |
                    2 |        \           |
                      |---------\--------->|
                    3 |          \         | 3  1 0 0
                      |           \------->|
                      |                    | 3  1 0 1
                      |                    |
                      V                    V

                                 Figure 6

   Figure 7 shows that the algorithm interprets duplication as
   reordering when a duplicated packet does not arrive in succession.
   It is not possible to hold all of the information contained in the
   arrival packets needed to measure accurately.

                           [astrncnt]................
                           [duptrcnt].............. :
                            [skipcnt]............ : :
                                                : : :
                            [recvseq].........  : : :
                    ........[sendseq]        :  : : :
                    :                        :  : : :
                      |                    |
                    0 |                    | 0  0 0 0
                      |------------------->|
                    1 |                    | 1  0 0 0
                      |------!DUP!-------->|
                    2 |         \          | 2  0 0 0
                      |----------\-------->|
                    3 |           \        | 3  0 0 0
                      |            \------>|
                      |                    | 3  0 0 1
                      V                    V

                                 Figure 7




Kikuchi, et al.         Expires November 22, 2008              [Page 14]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


7.  Security Considerations

   The passive measurements do not use any additional packets and flows,
   so that most security considerations boil down to the issues of the
   original protocols.  For example, fraud sequence numbers cause the
   measurement process to become disorganized.  This discussion boils
   down to the issues of the header protection.












































Kikuchi, et al.         Expires November 22, 2008              [Page 15]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


Appendix A.  Acknowledgements

   The authors would like to thank for helpful discussions in TEReCo 2.0
   research project sponsored in part by the ministry of internal
   affairs and communications Japan (SCOPE 072309007).














































Kikuchi, et al.         Expires November 22, 2008              [Page 16]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.kikuchi-tunnel-measure-req]
              Kikuchi, Y., Matsushima, S., Nagami, K., and S. Uda,
              "Quality Measurement Requirements for Tunneling
              Protocols", draft-kikuchi-tunnel-measure-req-02 (work in
              progress), November 2007.

   [I-D.morton-perf-metrics-framework]
              Morton, A., "Framework for Performance Metric
              Development", draft-morton-perf-metrics-framework-00 (work
              in progress), October 2007.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4908]  Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa,
              R., and H. Ohnishi, "Multi-homing for small scale fixed
              network Using Mobile IP and NEMO", RFC 4908, June 2007.






Kikuchi, et al.         Expires November 22, 2008              [Page 17]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


Authors' Addresses

   Yutaka Kikuchi
   Kochi University of Technology
   306B Research Collaboration Center
   185 Miyanokuchi, Tosayamada-cho
   Kami-shi, Kochi  782-0003
   JP

   Email: yu@kikuken.org


   Satoru Matsushima
   Softbank Telecom Corp.
   1-9-1 Higashi-Shinbashi, Minato-ku
   Tokyo
   JP

   Email: satoru@ft.solteria.net


   Ken-ichi Nagami
   Intec Netcore Inc.
   1-3-3, Shin-suna
   Koto-ku, Tokyo
   JP

   Email: nagami@inetcore.com


   Satoshi Uda
   Japan Advanced Institute of Science and Technology
   1-1 Asahi-dai
   Nomi-shi, Ishikawa-ken  923-1292
   JP

   Email: zin@jaist.ac.jp


   Nobuo Ogashiwa
   Maebashi Kyoai Gakuen College
   Koyahara 1154-4
   Maebashi, Gunma  379-2192
   JP

   Email: ogashiwa@c.kyoai.ac.jp





Kikuchi, et al.         Expires November 22, 2008              [Page 18]


Internet-Draft    draft-kikuchi-passive-measure-02.txt          May 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kikuchi, et al.         Expires November 22, 2008              [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/