Network Working Group Y. Kikuchi
Internet-Draft Kochi University of Technology
Expires: January 3, 2008 S. Matsushima
Softbank Telecom Corp.
K. Nagami
Intec Netcore Inc.
S. Uda
Japan Advanced Institute of
Science and Technology
N. Ogashiwa
Network Oriented Software Inc.
July 02, 2007
One-way Passive Measurement of End-to-End Quality
draft-kikuchi-passive-measure-00.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 January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kikuchi, et al. Expires January 3, 2008 [Page 1]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
Abstract
This draft describes a passive measurement method for one-way end-to-
end quality. The method consumes a small resources 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. Algorithm Behavior . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Kikuchi, et al. Expires January 3, 2008 [Page 2]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
1. Introduction
This draft describes a passive measurement method for one-way end-to-
end connections quality. The algorithm uses the sequence numbers of
the packets in a flow and consumes a small space and a small
computing power. Therefore, it is ease to apply to protocols that
have a sequence number field in their packet headers, such as GRE[2]
[3], PWE3[4] and RTP[5]. The method satisfies the quality
measurement requirements for tunneling protocols [6].
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 [1].
Kikuchi, et al. Expires January 3, 2008 [Page 3]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
2. Metrics
We firstly define the types of irregular packet.
o loss: packet that does not arrive in-sequence except duplication
o duplication: packet that is identical to the immediately preceding
arrival packet
o reordering: packet that arrives after the successive packets'
arrival
Note that ``duplication'' does not mean naive ``duplicate packets'',
because they should arrive uninterruptedly according to the
definition.
We secondly define the metrics of a channel as follows.
o The number of packets in each irregular type since the channel
appeared.[7]
Kikuchi, et al. Expires January 3, 2008 [Page 4]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
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
The egress host of a flow must have the following counters.
o recount: maintains the number that the successive packet should
have
o losscnt: the number of packets lost
o duplcnt: the number of packet duplications
o reodcnt: the number of reordering packets
Let the counters above be unsigned integer and initialized by 0. 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 "recvcnt" with the sequence number of the
packet named "seqno". The basic idea consists of the following
conditions.
1. if recvcnt and seqno are same then "in-sequence",
2. else if seqno is just a predecessor of recvcnt then "duplicate";
3. otherwise if seqno proceed then "loss" else "reordering".
The following C-like codes specifies the algorithm in detail. The
function measure will be invoked by every one of the reception of
packets.
Kikuchi, et al. Expires January 3, 2008 [Page 5]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
boolean measure(packet_t packet)
{
unsigned int seqno;
seqno = packet->header->seqno; // get seq # from header
if (seqno == recvcnt) { // no problem
recvcnt++;
return true;
} elsif (seqno+1 == recvcnt) { // same seq # as predecessor
duplcnt++;
return false;
}
signed int diff;
diff = (signed int)(seqno - recvcnt);
if (diff > 0) { // means skips some packets
losscnt += diff; // determines packets loss
recvcnt = seqno;
} else { // means it is a past packet
reodcnt++; // determines reordering
}
return false;
}
Figure 1
The function ``measure'' returns true only if the packet is
in_sequence. The value can be used to discard the packet when the
protocol does not allow to pass irregular packets to its higher
layer.
Kikuchi, et al. Expires January 3, 2008 [Page 6]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
4. 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 GRE tunnel 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 January 3, 2008 [Page 7]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
: : : : :
: : : : :
| |
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 January 3, 2008 [Page 8]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
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 January 3, 2008 [Page 9]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
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 can not distinguish a combination
of duplication and loss from a reordering. Compare the flow to
former of Figure 5.
Kikuchi, et al. Expires January 3, 2008 [Page 10]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
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 a 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.
[reodcnt]................
[duplcnt].............. :
[losscnt]............ : :
: : :
[recvcnt]......... : : :
........[sendcnt] : : : :
: : : : :
| |
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 January 3, 2008 [Page 11]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
5. Security Considerations
The passive measurements do not use any additional packets and flows,
so that most security considerations boils 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 January 3, 2008 [Page 12]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
Appendix A. Acknowledgements
The authors would like to thank for helpful discussions in TEReCo
research project sponsored in part by the ministry of internal
affairs and communications Japan (SCOPE 072309007).
Kikuchi, et al. Expires January 3, 2008 [Page 13]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[2] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[3] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[4] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[6] Kikuchi, Y., "Quality Measurement Requirements for Tunneling
Protocols", draft-kikuchi-tunnel-measure-req-00 (work in
progress), February 2007.
[7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[8] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
Kikuchi, et al. Expires January 3, 2008 [Page 14]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
Authors' Addresses
KIKUCHI Yutaka
Kochi University of Technology
306B Research Collaboration Center
185 Miyanokuchi, Tosayamada-cho
Kami-shi, Kochi 782-0003
JP
Email: yu@kikuken.org
MATSUSHIMA Satoru
Softbank Telecom Corp.
1-9-1 Higashi-Shinbashi, Minato-ku
Tokyo
JP
Email: satoru@ft.solteria.net
NAGAMI Ken'ichi
Intec Netcore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo
JP
Email: nagami@inetcore.com
UDA Satoshi
Japan Advanced Institute of Science and Technology
Email: zin@jaist.ac.jp
OGASHIWA Nobuo
Network Oriented Software Inc.
Email: ogashiwa@wide.ad.jp
Kikuchi, et al. Expires January 3, 2008 [Page 15]
Internet-Draft draft-kikuchi-passive-measure-00.txt July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kikuchi, et al. Expires January 3, 2008 [Page 16]