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]