Re: [Mobopts] Metrics definition for MIPv6 handover latency
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mobopts] Metrics definition for MIPv6 handover latency
Hi,
Attached is the draft document without the compression. Sorry for the inconvenience caused. Appreciate any comments and suggestions from you.
Regards,
Hongxia
----- Original Message -----
From: "Thomas C. Schmidt" <schmidt at informatik.haw-hamburg.de>
To: "Zheng Hongxia" <hxzheng at ict.ac.cn>
Sent: Tuesday, March 04, 2008 5:02 PM
Subject: Re: [Mobopts] Metrics definition for MIPv6 handover latency
> Hi Hongxia,
>
> can you please resend your draft without the compression?
>
> Thanks,
>
> thomas
>
> Zheng Hongxia wrote:
>> Hi all,
>>
>> My research team have paid great effort on MIPv6 handover
>> performance measurement in recent years. Maybe it is necessary to define
>> some performance metrics for mobile IP handover performance in a
>> RFC. Some suggestions about the metrics can be found in the attachment.
>> We would like to hear from you about the value and possibility to
>> propose such a draft. Any comment and suggestion are welcome. Thanks in
>> advance!
>>
>> Regards,
>> Hongxia
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mobopts mailing list
>> Mobopts at ietf.org
>> https://www.ietf.org/mailman/listinfo/mobopts
>
> --
>
> ° Prof. Dr. Thomas C. Schmidt
> ° HAW Hamburg, Dept. Informatik
> ° University of Applied Sciences
> ° Berliner Tor 7, D 20099 Hamburg
> ° Germany, Fon: +49-40-42875-8157
> ° http://www.informatik.haw-hamburg.de/~schmidt
>
>
June 2007
Metrics for MIPv6 Handover Latency
1. Introduction
Mobile IP allows nodes to remain reachable while moving around in the Internet. Mobility support in IP is particularly important, as mobile computers are likely to account for a majority or at least a substantial fraction of the population of the Internet. Handover is a particular procedure appeared in mobile networks. When a node moves, i.e. changes its point of attachment to the Internet, on IP layer, there is a process that a mobile node detects a change in an on-link subnet prefix that would require a change in the primary care-of address, which is called L3 handover in [RFC 3775], here it is called handover for short. Wherever handover is mentioned in following part of this memo, if not specified expressly, it means L3 handover. During a handover procedure, as the address of the node is changing, connection interruption, packet loss, etc. may occur. The period of time that a handover procedure costs is called handover latency in this memo. Handover latency can indicate how much handover affects communication quality, which is concerned by operators, managers and users of a mobile network.
This memo defines metrics for handover latency in MIPv6. Several handover mechanisms [RFC3775][RFC4068][RFC4140] have been proposed for mobile IPv6 today, this memo only focuses on the handover mechanism in [RFC 3775] at this time. This memo builds on notions introduced and discussed in the IPPM Framework document [RFC 2330] and MIPv6 protocol document [RFC3775]; the reader is assumed to be familiar with those documents.
Handover latency metrics are defined for a whole handover procedure and some typical stages of a whole handover procedure. Packets exchanged in a handover procedure to accomplish handover are called handover signalings in this memo. The start time point and the end time point used to measure handover latency are marked by specific MIPv6 handover signalings or procedures. Below is an illustration of the MIPv6 handover procedure in the view of handover signaling exchange, some signalings in the figure may only appear in special conditions, not always. For details of MIPv6 handover procedure or signalings, refer to [RFC3775].
Router on Foreign Link Mobile Node Home Agent Correspondent Node
| Router Solicitation(RS) | | |
|<------------------------| | |
|Router Advertisement(RA)| | |
|----------------------->| | |
|Neighbor Solicatation(NS)| | |
|<------------------------| | |
|Neighbor Advertisement(NA)| | |
|------------------------>| | |
| | Binding Update(BU)| |
| |-----------------> | |
| |Binding Acknowledgement(BA)| |
| |<------------------| |
| | Home Test Init(HoTI)| |
| |-------------------|-------------------> |
| | Care-of Test Init(CoTI) |
| |---------------------------------------> |
| | | Home Test(HoT) |
| |<------------------|-------------------- |
| | Care-of Test (CoT) |
| |<--------------------------------------- |
| | Binding Update(BU) |
| |---------------------------------------> |
| | Binding Acknowledgement (BA) |
| |<--------------------------------------- |
The memo was written by copying material from the Round-trip Delay metric [RFC2681] in some parts, especially those issues related to time. The intention is that, where the metrics are similar, they will be described with similar or identical text, and that where the metrics differ, new or modified text will be used.
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]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network.
Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, "term*" indicates that "term" is defined in the Framework.
1.1. Motivation:
The definitions of handover latency metrics intend to satisfy the goals of:
1. Quantifying the degree of handover latency of a handover procedure.
2. Quantifying the degree of handover latency of a stage in a handover procedure.
A handover latency metric is useful for several reasons:
+ Some up layer applications do not perform well (or at all) if handover latency is large relative to some threshold value.
+ Packet loss and transmission delay in IP layer will increase due to handover latency.
+ Erratic variation in handover latency makes it difficult (or impossible) to support many real-time applications.
+ The larger the value of handover latency, the more difficult it is for transport-layer protocols to sustain high bandwidths and sliding windows.
+ The value of the metrics indicate the effect of handover to communication and are an important factor for evaluation of the handover mechanism.
+ The values of handover latency for specific stages of a whole handover procedure indicate which stage accounts for big percentage of a whole handover procedure in the view of latency, which is beneficial for handover mechanisms research.
It is outside the scope of this document to say precisely how handover latency metrics would be applied to specific problems.
1.2. General Issues Regarding Time
{Comment: the terminology below differs from that defined by ITU-T
documents (e.g., G.810, "Definitions and terminology for
synchronization networks" and I.356, "B-ISDN ATM layer cell transfer
performance"), but is consistent with the IPPM Framework document.
In general, these differences derive from the different backgrounds;
the ITU-T documents historically have a telephony origin, while the
authors of this document (and the Framework) have a computer systems
background. Although the terms defined below have no direct
equivalent in the ITU-T definitions, after our definitions we will
provide a rough mapping. However, note one potential confusion: our
definition of "clock" is the computer operating systems definition
denoting a time-of-day clock, while the ITU-T definition of clock
denotes a frequency reference.}
Whenever a time (i.e., a moment in history) is mentioned here, it is understood to be measured in seconds (and fractions) relative to UTC.
As described more fully in the Framework document, there are four
distinct, but related notions of clock uncertainty:
synchronization*
measures the extent to which two clocks agree on what time it
is. For example, the clock on one host might be 5.4 msec ahead
of the clock on a second host.
accuracy*
measures the extent to which a given clock agrees with UTC.
For example, the clock on a host might be 27.1 msec behind UTC.
{Comment: A rough ITU-T equivalent is "time error from UTC".}
resolution*
measures the precision of a given clock. For example, the
clock on an old Unix host might tick only once every 10 msec,
and thus have a resolution of only 10 msec. {Comment: A very
rough ITU-T equivalent is "sampling period".}
skew*
measures the change of accuracy, or of synchronization, with
time. For example, the clock on a given host might gain 1.3
msec per hour and thus be 27.1 msec behind UTC at one time and
only 25.8 msec an hour later. In this case, we say that the
clock of the given host has a skew of 1.3 msec per hour
relative to UTC, which threatens accuracy. We might also speak
of the skew of one clock relative to another clock, which
threatens synchronization. {Comment: A rough ITU-T equivalent
is "time drift".}
2. A Singleton Definition for handover latency
2.1. Metric Name:
2.1.1. Whole-handover-latency
2.1.2. Movement-detection-handover-latency
2.1.3. Address-configuration-handover-latency
2.1.4. Home-agent-registration-handover-latency
2.1.5. Correspondent-node-registration-handover-latency
2.2. Metric Parameters:
+ Src, the Home IP address of mobile node
+ HDst, the IP address of Home Agent
+ CDst, the IP address of Correspondent node
+ T, a time
2.3. Metric Units:
2.3.1. Whole-handover-latency
The value of a Whole-handover-latency is either a real number, or an undefined (informally, infinite) number of seconds.
2.3.2. Movement-detection-handover-latency
The value of a Movement-detection-handover-latency is either a real number, or an undefined (informally, infinite) number of seconds.
2.3.3. Address-configuration-handover-latency
The value of an Address-configuration-handover-latency is either a real number, or an undefined (informally, infinite) number of seconds.
2.3.4. Home-agent-registration-handover-latency
The value of a Home-agent-registration-handover-latency is either a real number, or an undefined (informally, infinite) number of seconds.
2.3.5. Correspondent-node-registration-handover-latency
The value of a Correspondent-node-registration-handover-latency is either a real number, or an undefined (informally, infinite) number of seconds.
2.4. Definition:
2.4.1. Whole-handover-latency
When the handover happened, the mobile node loses its connectivity of current access point and connects to a neighboring new access point. As a result, the bidirectional communication between the mobile node and the correspondent node is interrupted during the handover procedure.
On the accurate definition, for a real number dT, >>the *Whole-handover-latency* for a mobile node at T is dT<< means that the mobile node¡¯s L2 handover is finished (For example, receiving the reassociation reply message at mobile node on 802.11 networks) at wire-time* T and that receives the last handover signaling at wire-time* T+dT.
>>The *Whole-handover-latency* for a mobile node at T is undefined (informally, infinite)<< means that the mobile node¡¯s L2 handover is finished at wire-time* T and that does not receive the last handover signaling for MAX_HANDOVER_TIME.
2.4.2. Movement-detection-handover-latency
When the mobile node attaches to a new subnet, it will receive the Router Advertisement message sent by the router of this subnet. For a real number dT, >>the *Movement-detection-handover-latency* for a mobile node at T is dT<< means that the mobile node¡¯s L2 handover is finished at wire-time* T and that receives the Router Advertisement message at wire-time T+dT.
>>The *Movement-detection-handover-latency* for a mobile node at T is undefined (informally, infinite)<< means that the mobile node¡¯s L2 handover is finished at wire-time* T and that does not receive the Router Advertisement message within the duration longer than MAX_MOV_DETECTION_TIME.
(The discussion of this metric will be given in 2.5.5 and 2.7.3.)
2.4.3. Address-configuration-handover-latency
When the mobile node received the Router Advertisement message of a new attachment network, it will configure its new care-of-address(COA) by fetching the prefix from the Router Advertisement message and do the Duplicate Address Detection procedure. After that, the mobile node will send the Binding Update message to HDst to register its COA. For a real number dT, >>the *Address-configuration-handover-latency* for a mobile node at T is dT<< means that the mobile node receives the Router Advertisement message at wire-time T and that sends the Binding Update message to HDst at wire-time T+dT.
>>The *Address-configuration-handover-latency* for a mobile node at T is undefined (informally, infinite)<< means that the mobile node receives the Router Advertisement message at wire-time* T and that can not send the Binding Update message to HDst after MAX_ADDRE_CONF_TIME because of failed configuration for new COA.
2.4.4. Home-agent-registration-handover-latency
When the mobile node successfully configures this new COA, it should register this COA with its Home Agent in order to make this its primary COA. For a real number dT, >>the *Home-agent-registration-handover-latency* for a mobile node at T is dT<< means that the mobile node sends Binding Update message to HDst at wire-time T and that receives the corresponding Binding Acknowledgement message from HDst at wire-time T+dT.
>>The *Home-agent-registration-handover-latency* for a mobile node at T is undefined (informally, infinite)<< means that the mobile node sends the Binding Update message to HDst at wire-time* T and that does not receive the corresponding Binding Ackonwledge message from HDst for MAX_HA_REG_TIME.
2.4.5. Correspondent-node-registration-handover-latency
As the registration of its new COA with Home Agent, the mobile node sends a Binding Update message to each CDst to inform them of its new location. For a real number dT, >>the *Correspondent-node-registration-handover-latency* for a mobile node at T is dT<< means that the mobile node sends the Home Test Init Message (under the circumstance that it is sent before the Care-of Test Init Message) or Care-of Test Init Message (correspondingly, if it is sent before the Home Test Init Message) at wire-time T and that receives the Binding Update message from the CDst at wire-time T+dT.
>>The *Correspondent-node-registration-handover-latency* for a mobile node at T is undefined (informally, infinite)<< means that the mobile node sends the Home Test Init Message or Care-of Test Init Message at wire-time* T and that does not receive the Binding Acknowledgement message from CDst for MAX_CN_REG_TIME.
Suggestions for what to report along with metric values appear in
Section 2.8 after a discussion of the metric, methodologies for
measuring the metric, and error analysis.
2.5. Discussion:
2.5.1. Address configuration
The mobile node can acquire its care-of address through stateless or stateful address configuration. The stateful address configuration will incur more overhead time than stateless address configuration. For the sake of the efficiency of handover, using stateless address configuration is probably the preferred option.
2.5.2. Different movement scene
In the different movement scene, the whole-handover-latency time will have different end point.
In the scene of the mobile node moves from Home network to a foreign network and another scene of the mobile node moves from one foreign network to another foreign network and the correspondent node does not support Mobile IPv6, the end point of the whole handover is the completion of Home Agent registration. In other words, when the mobile node receives the corresponding Binding Acknowledgement message from HDst, the bidirectional communication will be recovered and packets can be transport through the bidirectional tunneling.
In the scene of the mobile node moves from one foreign network to another foreign network and the correspondent node supports Mobile IPv6, the end point of the whole handover is the completion of correspondent node registration. In other words, when the mobile node receives the corresponding Binding Acknowledgement message from CDst, the bidirectional communication will be recovered and packets can be routed directly to the care-of address of the mobile node.
2.5.3. Sequence about Home Test Init Message and Care-of Test Init Messages
The mobile node sends a Home Test Init Message and a Care-of Test Init Messages in parallel at a return routability procedure [Rfc 3775]. Hence, the sequence of the appearances of the two messages on wire-time* is uncertain.
2.5.4. Start of handover
The detection of handover includes three issues:
. L2 handover has happened and has been finished
. Receipt of Router Advertisement message containing a different set of on-link prefixes
. The default router is no longer bi-directionally reachable
As mentioned above, we make the time point of the finished time of L2 handover as the beginning of whole-handover-delay and movement-detection-handover-delay, and must make sure it would have the other two indications in addition.
2.5.5. Issues come up in practice
Real handover latency values will be positive. Therefore, it does not make sense to report a negative value as a real handover latency.
A given methodology will have to include a way to determine whether a handover latency value is infinite or whether it is merely very large.
2.6. Methodologies:
The detailed methodology for Whole-handover-latency will depend on the different movement scene.
In the scene of the mobile node moves from Home network to a foreign network and another scene of the mobile node moves from one foreign network to another foreign network with the correspondent node having no support for Mobile IPv6, the methodology would proceed as follows:
+ At the mobile node, if the handover occurred, take a timestamp as soon as possible when the L2 handover is finished.
+ If the Binding Acknowledgement message sent by HDst arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of Whole-handover-latency can be computed.
+ If the Binding Acknowledgement message sent by Home Agent fails to arrive within a reasonable period of time, the Whole-handover-latency is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
In the scene of the mobile node moves from one foreign network to another foreign network with the correspondent node supporting Mobile IPv6, the methodology would proceed as follows:
+ At the mobile node, if the handover occurred, take a timestamp as
soon as possible when the L2 handover is finished.
+ If the Binding Acknowledgement message sent by correspondent node arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of Whole-handover-latency can be computed.
+ If the Binding Acknowledgement message sent by correspondent node fails to arrive within a reasonable period of time, the Whole-handover-latency is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
The detailed methodology for Movement-detection-handover-latency would
proceed as follows:
+ At the mobile node, if the handover occurred, take a timestamp as soon as possible when the L2 handover is finished.
+ If the Router Advertisement message sent by the new attachment subnet default router arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of Movement-detection-handover-latency can be computed.
+ If the Router Advertisement message sent by the new attachment subnet default router fails to arrive within a reasonable period of time, the Movement-detection-handover-latency is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
{Comment: The methodology for Whole-handover-latency and Movement-detection-handover-latency MUST make sure that the old default router is not bi-directionally reachable definitely. If the old default router is still bi-directionally reachable, the measurement of whole-handover-delay and movement-detection-handover-delay MUST be abort. The concrete methodology for check the bi-directional reachability of the old default router is outside the scope of this document.}
The detailed methodology for Address-configuration-handover-latency
would proceed as follows:
+ At the mobile node, take a timestamp as soon as possible upon the receipt of Router Advertisement message sent by the new attachment subnet default router.
+ Take the timestamp as soon as possible upon the sending of the Binding Update message from mobile node to HDst if the message is sent by mobile node within a reasonable period of time. By subtracting the two timestamps, an estimate of Address-configuration-handover-latency can be computed.
+ If the Binding Update message fails to send within a reasonable period of time at the mobile node, the Address-configuration-handover-latency is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
The detailed methodology for Home-agent-registration-handover-latency would proceed as follows:
+ At the mobile node, take a timestamp as soon as possible upon the sending of the Binding Update message from mobile node to HDst.
+ Take the timestamp as soon as possible upon the receipt of the Binding Acknowledgement message from HDst to the mobile node if the message is received at mobile node within a reasonable period of time. By subtracting the two timestamps, an estimate Home-agent-registration-handover-latency can be computed.
+ If the Binding Acknowledgement message fails to receive within a reasonable period of time at the mobile node, the Home-agent-registration-handover-latency is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
The detailed methodology for Correspondent-node-registration-handover-latency would proceed as follows:
+ At the mobile node, take a timestamp as soon as possible upon the sending of the earlier one of Home Test Init Message and Care-of Test Init Message from mobile node to CDst.
+ Take the timestamp as soon as possible upon the receipt of the Binding Acknowledgement message from CDst to the mobile node if the message is received at mobile node within a reasonable period of time. By subtracting the two timestamps, an estimate Correspondent-node-registration-handover-latency can be computed.
+ If the Binding Acknowledgement message fails to receive within a reasonable period of time at the mobile node, the Correspondent-node-registration-handover-latency is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
Issues such as how to trigger handover is outside the scope of this document.
2.7. Errors and Uncertainties:
The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty.
The Framework document provides general guidance on this point, but we note here the following specifics related to delay metrics:
+ Errors or uncertainties due to uncertainty in the clock of the Src
host.
+ Errors or uncertainties due to the difference between 'wire time'
and 'host time'.
In addition, the loss threshold may affect the results. Each of these is discussed in more detail below, along with a section ("Calibration") on accounting for these errors and uncertainties.
2.7.1. Errors or Uncertainties Related to Clocks
The uncertainty in a measurement of handover latency is related, in
part, to uncertainty in the clock of the Src host. In the following,
we refer to the clock used to measure when the handover signaling marking start of a handover procedure was captured on Src as the source clock, and we refer to the observed time when the signaling was captured on Src as Tinitial, and the observed time when the handover signaling marking end of a handover procedure was captured on Src as Tfinal. Alluding to the notions of synchronization, accuracy, resolution, and skew mentioned in the Introduction, we note the following:
+ There is an issue of self-synchronization between the source clock at the time the handover signaling marking start of a handover procedure is captured and the (same) source clock at the time the handover signaling marking end of a handover procedure is captured. Theoretically a very severe case of skew could threaten this. In practice, the greater threat is anything that would cause a discontinuity in the source clock during the time between the taking of the initial and final timestamp. This might happen, for example, with certain implementations of NTP.
+ The accuracy of a clock is important only in identifying the time
at which a given handover latency was measured. Accuracy, per se, has no importance to the accuracy of the measurement of handover latency.
+ The resolution of a clock adds to uncertainty about any time measured with it. Thus, if the source clock has a resolution of
10 msec, then this adds 10 msec of uncertainty to any time value
measured with it. We will denote the resolution of the source
clock as Rsource.
Taking these items together, we note that naive computation Tfinal-
Tinitial will be off by 2*Rsource.
2.7.2. Errors or Uncertainties Related to Wire-time vs Host-time
As we have defined handover latency, we would like to measure the
time between when the handover signaling marking start of a handover procedure is captured at the network interface of Src and when the handover signaling marking end of a handover procedure is captured at the network interface of Src, and we refer to these as "wire times".
If the timings are themselves performed by software on Src, however,
then this software can only directly measure the time between when Src grabs a timestamp differ to capturing the start signaling and when it grabs a timestamp differ to capturing the end signaling, and we refer to these two points as "host times".
To the extent that the difference between wire time and host time is
accurately known, this knowledge can be used to correct for host time
measurements and the corrected value more accurately estimates the
desired (wire time) metric.
To the extent, however, that the difference between wire time and
host time is uncertain, this uncertainty must be accounted for in an
analysis of a given measurement method. We denote by Hinitial an
upper bound on the uncertainty in the difference between wire time
and host time on the Src host in capturing the start signaling, and
similarly define Hfinal for the difference on the Src host in capturing the end signaling. We then note that these problems introduce a total uncertainty of Hinitial + Hfinal. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
2.7.3. Calibration
Generally, the measured values can be decomposed as follows:
measured value = true value + systematic error + random error
If the systematic error (the constant bias in measured values) can be
determined, it can be compensated for in the reported results.
reported value = measured value - systematic error
therefore
reported value = true value + random error
The goal of calibration is to determine the systematic and random
error generated by the instruments themselves in as much detail as
possible. At a minimum, a bound ("e") should be found such that the
reported value is in the range (true value - e) to (true value + e)
at least 95 percent of the time. We call "e" the calibration error
for the measurements. It represents the degree to which the values
produced by the measurement instrument are repeatable; that is, how
closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95
percent was chosen because (1) some confidence level is desirable to
be able to remove outliers, which will be found in measuring any
physical property; and (2) a particular confidence level should be
specified so that the results of independent implementations can be
compared.}
From the discussion in the previous sections, the error in measurements could be bounded by determining all the individual
uncertainties, and adding them together to form
2*Rsource + Hinitial + Hfinal.
However, reasonable bounds on both the clock-related uncertainty
captured by the first term and the host-related uncertainty captured
by the last two terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab.
For handover latency, the host-related uncertainties, Hinitial + Hfinal are only related to the Src host and have little relations with network connection style. The measured handover latency therefore can be seen as containing only systematic and random error in the instrumentation. The "average value" of repeated measurements is the systematic error, and the variation is the random error.
One way to compute the systematic error, and the random error to a
95% confidence is to repeat the experiment many times - at least
hundreds of tests. The systematic error would then be the median.
The random error could then be found by removing the systematic error
from the measured values. The 95% confidence interval would be the
range from the 2.5th percentile to the 97.5th percentile of these
deviations from the true value. The calibration error "e" could then
be taken to be the largest absolute value of these two numbers, plus
the clock-related uncertainty. {Comment: as described, this bound is
relatively loose since the uncertainties are added, and the absolute
value of the largest deviation is used. As long as the resulting
value is not a significant fraction of the measured values, it is a
reasonable bound. If the resulting value is a significant fraction
of the measured values, then more exact methods will be needed to
compute the calibration error.}
We wish to reiterate that this statistical treatment refers to the
calibration of the instrument; it is used to "calibrate the meter
stick" and say how well the meter stick reflects reality.
In addition to calibrating the instruments for finite delay, two checks should be made to ensure that packets reported as losses were really lost. First, the threshold for loss should be verified. In particular, ensure the "reasonable" threshold is reasonable: that it is very unlikely a packet will arrive after the threshold value, and therefore the number of packets lost over an interval is not sensitive to the error bound on measurements. Second, consider the possibility that a packet arrives at the network interface, but is lost due to congestion on that interface or to other resource exhaustion (e.g. buffers) in the instrument.
2.8. Reporting the metric:
The calibration and context in which the metric is measured MUST be carefully considered, and SHOULD always be reported along with metric results. We now present one items to consider: the movement scene, the threshold of infinite delay (if any), error calibration. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported.
2.8.1. Movement scene
As mentioned in 2.5.3, the value of whole-handover-latency metric depends on movement scene. Therefore, the exact movement scene related to whole-handover-latency MUST be accurately reported.
2.8.2. Loss threshold
In addition, the threshold (or methodology to distinguish) between a
large finite delay and loss MUST be reported.
2.8.3. Calibration Results
+ If the systematic error can be determined, it SHOULD be removed
from the measured values.
+ You SHOULD also report the calibration error, e, such that the
true value is the reported value plus or minus e, with 95% confidence (see the last section).
+ If possible, the conditions under which a handover signaling with finite delay is reported as lost due to resource exhaustion on the
measurement instrument SHOULD be reported.
2.9 Time Constants
MAX_MOV_DETECTION_TIME is the maximum time spends on Movement detection procedure. We define the default value of MAX_MOV_DETECTION_TIME as RStime + MAX_RTR_SOLICITATION_DELAY[Rfc2461] + RTR_SOLICITATION_INTERVAL[Rfc2461] * MAX_RTR_SOLICITATIONS[Rfc2461] + MAX_RTR_SOLICITATION_DELAY[Rfc2461].(The RStime is the duration of the finished time of L2 handover and sending of router solicitation on mobile node.)
MAX_ADDRE_CONF_TIME is the maximum time spends on address configuration. The default value is defined to RETRANS_TIMER[Rfc2462] * DupAddrDetectTransmits[Rfc2462] due to the Duplicate Address Detection procedure refer to Rfc 2462.
MAX_HA_REG_TIME is the maximum time spends on Home Agent registration procedure. We define the default value of the MAX_BINDACK_TIMEOUT as MAX_HA_REG_TIME [Rfc3775] refer to Rfc 3775.
MAX_CN_REG_TIME is the maximum time spends on Correspondent node registration procedure. On the same consideration, we define the default value of the MAX_CN_REG_TIME as MAX_HA_REG_TIME[Rfc3775] refer to Rfc 3775.
MAX_HANDOVER_TIME is the maximum time spends on mobile IPv6 handover. None of whole-handover-latency time will be possible to bigger than MAX_MOV_DETECTION_TIME + MAX_ADDRE_CONF_TIME + MAX_HA_REG_TIME + MAX_CN_REG_TIME. Hence we define MAX_MOV_DETECTION_TIME + MAX_ADDRE_CONF_TIME + MAX_HA_REG_TIME + MAX_CN_REG_TIME as the default value of MAX_HANDOVER_TIME.
3.References
[RFC2330] Paxson, D., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC3775] D. Johnson, C. Perkins, J. Arkko, ¡°Mobility Support in IPv6¡±, RFC 3775, June 2004.
[RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, ¡°A Round-trip Delay Metric for IPPM¡±, RFC 2681, September 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC4068] R. Koodli, Ed., ¡°Fast Handovers for Mobile IPv6¡±, RFC 4068, July 2005.
[RFC4140] H. Soliman, C. Castelluccia, K. El Malki, L. Bellier, ¡°Hierarchical Mobile IPv6 Mobility Management (HMIPv6)¡±, RFC 4140, August 2005.
[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] S. Thomson, T. Narten, ¡°IPv6 Stateless Address Autoconfiguration¡±, RFC 2462, December 1998.
_______________________________________________
Mobopts mailing list
Mobopts at ietf.org
https://www.ietf.org/mailman/listinfo/mobopts
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
