draft-ietf-ippm-testplan-rfc2680-04.txt   draft-ietf-ippm-testplan-rfc2680-05.txt 
Network Working Group L. Ciavattone Network Working Group L. Ciavattone
Internet-Draft AT&T Labs Internet-Draft AT&T Labs
Intended status: Informational R. Geib Intended status: Informational R. Geib
Expires: April 21, 2014 Deutsche Telekom Expires: October 5, 2014 Deutsche Telekom
A. Morton A. Morton
AT&T Labs AT&T Labs
M. Wieser M. Wieser
Technical University Darmstadt Technical University Darmstadt
October 18, 2013 April 3, 2014
Test Plan and Results for Advancing RFC 2680 on the Standards Track Test Plan and Results for Advancing RFC 2680 on the Standards Track
draft-ietf-ippm-testplan-rfc2680-04 draft-ietf-ippm-testplan-rfc2680-05
Abstract Abstract
This memo proposes to advance a performance metric RFC along the This memo proposes to advance a performance metric RFC along the
standards track, specifically RFC 2680 on One-way Loss Metrics. standards track, specifically RFC 2680 on One-way Loss Metrics.
Observing that the metric definitions themselves should be the Observing that the metric definitions themselves should be the
primary focus rather than the implementations of metrics, this memo primary focus rather than the implementations of metrics, this memo
describes the test procedures to evaluate specific metric requirement describes the test procedures to evaluate specific metric requirement
clauses to determine if the requirement has been interpreted and clauses to determine if the requirement has been interpreted and
implemented as intended. Two completely independent implementations implemented as intended. Two completely independent implementations
have been tested against the key specifications of RFC 2680. have been tested against the key specifications of RFC 2680.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2014. This Internet-Draft will expire on October 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. RFC 2680 Coverage . . . . . . . . . . . . . . . . . . . . 5 1.1. RFC 2680 Coverage . . . . . . . . . . . . . . . . . . . . 4
2. A Definition-centric metric advancement process . . . . . . . 5 2. A Definition-centric metric advancement process . . . . . . . 4
3. Test configuration . . . . . . . . . . . . . . . . . . . . . . 5 3. Test configuration . . . . . . . . . . . . . . . . . . . . . 4
4. Error Calibration, RFC 2680 . . . . . . . . . . . . . . . . . 9 4. Error Calibration, RFC 2680 . . . . . . . . . . . . . . . . . 9
4.1. Clock Synchronization Calibration . . . . . . . . . . . . 9 4.1. Clock Synchronization Calibration . . . . . . . . . . . . 9
4.2. Packet Loss Determination Error . . . . . . . . . . . . . 10 4.2. Packet Loss Determination Error . . . . . . . . . . . . . 10
5. Pre-determined Limits on Equivalence . . . . . . . . . . . . . 10 5. Pre-determined Limits on Equivalence . . . . . . . . . . . . 10
6. Tests to evaluate RFC 2680 Specifications . . . . . . . . . . 11 6. Tests to evaluate RFC 2680 Specifications . . . . . . . . . . 11
6.1. One-way Loss, ADK Sample Comparison . . . . . . . . . . . 11 6.1. One-way Loss, ADK Sample Comparison . . . . . . . . . . . 11
6.1.1. 340B/Periodic Cross-imp. results . . . . . . . . . . . 12 6.1.1. 340B/Periodic Cross-imp. results . . . . . . . . . . 12
6.1.2. 64B/Periodic Cross-imp. results . . . . . . . . . . . 13 6.1.2. 64B/Periodic Cross-imp. results . . . . . . . . . . . 13
6.1.3. 64B/Poisson Cross-imp. results . . . . . . . . . . . . 14 6.1.3. 64B/Poisson Cross-imp. results . . . . . . . . . . . 14
6.1.4. Conclusions on the ADK Results for One-way Packet 6.1.4. Conclusions on the ADK Results for One-way Packet
Loss . . . . . . . . . . . . . . . . . . . . . . . . . 15 Loss . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. One-way Loss, Delay threshold . . . . . . . . . . . . . . 15 6.2. One-way Loss, Delay threshold . . . . . . . . . . . . . . 15
6.2.1. NetProbe results for Loss Threshold . . . . . . . . . 16 6.2.1. NetProbe results for Loss Threshold . . . . . . . . . 16
6.2.2. Perfas Results for Loss Threshold . . . . . . . . . . 17 6.2.2. Perfas Results for Loss Threshold . . . . . . . . . . 17
6.2.3. Conclusions for Loss Threshold . . . . . . . . . . . . 17 6.2.3. Conclusions for Loss Threshold . . . . . . . . . . . 17
6.3. One-way Loss with Out-of-Order Arrival . . . . . . . . . . 17
6.4. Poisson Sending Process Evaluation . . . . . . . . . . . . 18 6.3. One-way Loss with Out-of-Order Arrival . . . . . . . . . 17
6.4.1. NetProbe Results . . . . . . . . . . . . . . . . . . . 19 6.4. Poisson Sending Process Evaluation . . . . . . . . . . . 18
6.4.2. Perfas+ Results . . . . . . . . . . . . . . . . . . . 20 6.4.1. NetProbe Results . . . . . . . . . . . . . . . . . . 19
6.4.3. Conclusions for Goodness-of-Fit . . . . . . . . . . . 22 6.4.2. Perfas+ Results . . . . . . . . . . . . . . . . . . . 20
6.5. Implementation of Statistics for One-way Loss . . . . . . 22 6.4.3. Conclusions for Goodness-of-Fit . . . . . . . . . . . 22
7. Conclusions for RFC 2680bis . . . . . . . . . . . . . . . . . 23 6.5. Implementation of Statistics for One-way Loss . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Conclusions for RFC 2680bis . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11. Appendix - Network Configuration and sample commands . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The IETF (IP Performance Metrics working group, IPPM) has considered The IETF (specifically the IP Performance Metrics working group, or
how to advance their metrics along the standards track since 2001. IPPM) has considered how to advance their metrics along the standards
track since 2001.
The renewed work effort sought to investigate ways in which the The renewed work effort sought to investigate ways in which the
measurement variability could be reduced and thereby simplify the measurement variability could be reduced and thereby simplify the
problem of comparison for equivalence. As a result, there is problem of comparison for equivalence. As a result, there is
consensus (captured in [RFC6576]) that equivalent results from consensus (captured in [RFC6576]) that equivalent results from
independent implementations of metric specifications are sufficient independent implementations of metric specifications are sufficient
evidence that the specifications themselves are clear and evidence that the specifications themselves are clear and
unambiguous; it is the parallel concept of protocol interoperability unambiguous; it is the parallel concept of protocol interoperability
for metric specifications. The advancement process either produces for metric specifications. The advancement process either produces
confidence that the metric definitions and supporting material are confidence that the metric definitions and supporting material are
skipping to change at page 6, line 23 skipping to change at page 6, line 23
+-+--+---+ |Router| | | +---+---+--+--+--+----+ +-+--+---+ |Router| | | +---+---+--+--+--+----+
|__| +--A---+ ( ) |Network| |__| |__| +--A---+ ( ) |Network| |__|
\ / |Emulat.| \ / |Emulat.|
U-turn \ / |"netem"| U-turn U-turn \ / |"netem"| U-turn
V300 to V400 `-+-' +-------+ V100 to V200 V300 to V400 `-+-' +-------+ V100 to V200
Implementations ,---. +--------+ Implementations ,---. +--------+
+~~~~~~~~~~~/ \~~~~~~| Remote | +~~~~~~~~~~~/ \~~~~~~| Remote |
+------->-----F2->-| / \ |->---. | +------->-----F2->-| / \ |->---. |
| +---------+ | Tunnel ( ) | | | | +---------+ | Tunnel ( ) | | |
| | transmit|-F1->-| ID 1 ( ) |->. | | | | transmit|-F1->-| ID 1 | | |->. | |
| | Imp 1 | +~~~~~~~~~| |~~~~| | | | | | Imp 1 | +~~~~~~~~~| |~~~~| | | |
| | receive |-<--+ ( ) | F1 F2 | | | receive |-<--+ | | | F1 F2 |
| +---------+ | |Internet | | | | | | +---------+ | |Internet | | | | |
*-------<-----+ F1 | | | | | | *-------<-----+ F1 | | | | | |
+---------+ | | +~~~~~~~~~| |~~~~| | | | +---------+ | | +~~~~~~~~~| |~~~~| | | |
| transmit|-* *-| | | |<-* | | | transmit|-* *-| | | |<-* | |
| Imp 2 | | Tunnel ( ) | | | | Imp 2 | | Tunnel ( ) | | |
| receive |-<-F2-| ID 2 \ / |<----* | | receive |-<-F2-| ID 2 \ / |<----* |
+---------+ +~~~~~~~~~~~\ /~~~~~~| Switch | +---------+ +~~~~~~~~~~~\ /~~~~~~| Switch |
`-+-' +--------+ `-+-' +--------+
Illustrations of a test setup with a bi-directional tunnel. The Illustrations of a test setup with a bi-directional tunnel. The
skipping to change at page 7, line 21 skipping to change at page 7, line 22
The network emulator is a host running Fedora 14 Linux [Fedora] with The network emulator is a host running Fedora 14 Linux [Fedora] with
IP forwarding enabled and the "netem" Network emulator as part of the IP forwarding enabled and the "netem" Network emulator as part of the
Fedora Kernel 2.6.35.11 [netem] loaded and operating. The standard Fedora Kernel 2.6.35.11 [netem] loaded and operating. The standard
kernel is "tickless" replacing the previous periodic timer (250HZ, kernel is "tickless" replacing the previous periodic timer (250HZ,
with 4ms uncertainty) interrupts with on-demand interrupts. with 4ms uncertainty) interrupts with on-demand interrupts.
Connectivity across the netem/Fedora host was accomplished by Connectivity across the netem/Fedora host was accomplished by
bridging Ethernet VLAN interfaces together with "brctl" commands bridging Ethernet VLAN interfaces together with "brctl" commands
(e.g., eth1.100 <-> eth2.100). The netem emulator was activated on (e.g., eth1.100 <-> eth2.100). The netem emulator was activated on
one interface (eth1) and only operates on test streams traveling in one interface (eth1) and only operates on test streams traveling in
one direction. In some tests, independent netem instances operated one direction. In some tests, independent netem instances operated
separately on each VLAN. separately on each VLAN. See the Appendix for more details.
The links between the netem emulator host and router and switch were The links between the netem emulator host and router and switch were
found to be 100baseTx-HD (100Mbps half duplex) as reported by "mii- found to be 100baseTx-HD (100Mbps half duplex) as reported by "mii-
tool" [mii-tool], when testing was complete. Use of half duplex was tool" [mii-tool], when testing was complete. Use of half duplex was
not intended, but probably added a small amount of delay variation not intended, but probably added a small amount of delay variation
that could have been avoided in full duplex mode. that could have been avoided in full duplex mode.
Each individual test was run with common packet rates (1 pps, 10pps) Each individual test was run with common packet rates (1 pps, 10pps)
Poisson/Periodic distributions, and IP packet sizes of 64, 340, and Poisson/Periodic distributions, and IP packet sizes of 64, 340, and
500 Bytes. 500 Bytes.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
encapsulation). encapsulation).
4. Error Calibration, RFC 2680 4. Error Calibration, RFC 2680
An implementation is required to report calibration results on clock An implementation is required to report calibration results on clock
synchronization in Section 2.8.3 of [RFC2680] (also required in synchronization in Section 2.8.3 of [RFC2680] (also required in
Section 3.7 of [RFC2680] for sample metrics). Section 3.7 of [RFC2680] for sample metrics).
Also, it is recommended to report the probability that a packet Also, it is recommended to report the probability that a packet
successfully arriving at the destination network interface is successfully arriving at the destination network interface is
incorrectly designated as lost due to resource exhaustion in Section incorrectly designated as lost due to resource exhaustion in
2.8.3 of [RFC2680]. Section 2.8.3 of [RFC2680].
4.1. Clock Synchronization Calibration 4.1. Clock Synchronization Calibration
For NetProbe and Perfas+ clock synchronization test results, refer to For NetProbe and Perfas+ clock synchronization test results, refer to
Section 4 of [RFC6808]. Section 4 of [RFC6808].
4.2. Packet Loss Determination Error 4.2. Packet Loss Determination Error
Since both measurement implementations have resource limitations, it Since both measurement implementations have resource limitations, it
is theoretically possible that these limits could be exceeded and a is theoretically possible that these limits could be exceeded and a
packet that arrived at the destination successfully might be packet that arrived at the destination successfully might be
discarded in error. discarded in error.
In previous test efforts [I-D.morton-ippm-advance-metrics], NetProbe In previous test efforts [I-D.morton-ippm-advance-metrics], NetProbe
produced 6 multicast streams with an aggregate bit rate over 53 produced 6 multicast streams with an aggregate bit rate over 53 Mbit/
Mbit/s, in order to characterize the 1-way capacity of a NISTNet- s, in order to characterize the 1-way capacity of a NISTNet-based
based emulator. Neither the emulator nor the pair of NetProbe emulator. Neither the emulator nor the pair of NetProbe
implementations used in this testing dropped any packets in these implementations used in this testing dropped any packets in these
streams. streams.
The maximum load used here between any 2 NetProbe implementations was The maximum load used here between any 2 NetProbe implementations was
11.5 Mbit/s divided equally among 3 unicast test streams. We 11.5 Mbit/s divided equally among 3 unicast test streams. We
concluded that steady resource usage does not contribute error concluded that steady resource usage does not contribute error
(additional loss) to the measurements. (additional loss) to the measurements.
5. Pre-determined Limits on Equivalence 5. Pre-determined Limits on Equivalence
skipping to change at page 11, line 4 skipping to change at page 10, line 52
o 0.95 confidence factor at 1 packet resolution, or o 0.95 confidence factor at 1 packet resolution, or
o the smallest confidence factor (in combination with resolution) of o the smallest confidence factor (in combination with resolution) of
the two same-implementation comparisons for the same test the two same-implementation comparisons for the same test
conditions (if the number of streams is sufficient to allow such conditions (if the number of streams is sufficient to allow such
comparisons). comparisons).
For Anderson-Darling Goodness-of-Fit (ADGoF) [Radgof] comparisons, For Anderson-Darling Goodness-of-Fit (ADGoF) [Radgof] comparisons,
the required level of significance for the same-implementation the required level of significance for the same-implementation
Goodness-of-Fit (GoF) SHALL be 0.05 or 5%, as specified in Section Goodness-of-Fit (GoF) SHALL be 0.05 or 5%, as specified in
11.4 of [RFC2330]. This is equivalent to a 95% confidence factor. Section 11.4 of [RFC2330]. This is equivalent to a 95% confidence
factor.
6. Tests to evaluate RFC 2680 Specifications 6. Tests to evaluate RFC 2680 Specifications
This section describes some results from production network (cross- This section describes some results from production network (cross-
Internet) tests with measurement devices implementing IPPM metrics Internet) tests with measurement devices implementing IPPM metrics
and a network emulator to create relevant conditions, to determine and a network emulator to create relevant conditions, to determine
whether the metric definitions were interpreted consistently by whether the metric definitions were interpreted consistently by
implementors. implementors.
The procedures are similar contained in Appendix A.1 of [RFC6576] for The procedures are similar contained in Appendix A.1 of [RFC6576] for
skipping to change at page 24, line 15 skipping to change at page 24, line 20
Nicole Kowalski supplied the needed CPE router for the NetProbe side Nicole Kowalski supplied the needed CPE router for the NetProbe side
of the test set-up, and graciously managed her testing in spite of of the test set-up, and graciously managed her testing in spite of
issues caused by dual-use of the router. Thanks Nicole! issues caused by dual-use of the router. Thanks Nicole!
The "NetProbe Team" also acknowledges many useful discussions on The "NetProbe Team" also acknowledges many useful discussions on
statistical interpretation with Ganga Maguluri. statistical interpretation with Ganga Maguluri.
Constructive comments and helpful reviews where also provided by Bill Constructive comments and helpful reviews where also provided by Bill
Cerveny, Joachim Fabini, and Ann Cerveny. Cerveny, Joachim Fabini, and Ann Cerveny.
11. References 11. Appendix - Network Configuration and sample commands
11.1. Normative References This Appendix provides some background information on the host
configuration and sample tc commands for the "netem" network
emulator, as described in Section 3 and Figure 1 in the body of this
memo. These details are also applicable to the test plan in
[RFC6808].
The host interface and configuration is shown below:
[system@dell4-4 ~]$ su
Password:
[root@dell4-4 system]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@dell4-4 system]# service iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: nat filter [ OK ]
iptables: Unloading modules: [ OK ]
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
[root@dell4-4 system]# ifconfig eth1.300 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth1.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.300 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br300
[root@dell4-4 system]# brctl addif br300 eth1.300
[root@dell4-4 system]# brctl addif br300 eth2.300
[root@dell4-4 system]# ifconfig br300 up
[root@dell4-4 system]# brctl addbr br400
[root@dell4-4 system]# brctl addif br400 eth1.400
[root@dell4-4 system]# brctl addif br400 eth2.400
[root@dell4-4 system]# ifconfig br400 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# brctl showmacs br300
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:02:b3:c4:c9:7a no 0.52
2 00:02:b3:cf:02:c6 no 0.52
2 00:0b:5f:54:de:81 no 0.01
[root@dell4-4 system]# brctl showmacs br400
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:02:b3:c4:c9:7a no 0.60
1 00:02:b3:cf:02:c6 no 0.42
2 00:0b:5f:54:de:81 no 0.33
[root@dell4-4 system]# tc qdisc add dev eth1.300 root netem delay 100ms
[root@dell4-4 system]# ifconfig eth1.200 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth1 100
Added VLAN with VID == 100 to IF -:eth1:-
[root@dell4-4 system]# ifconfig eth1.100 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth2 100
Added VLAN with VID == 100 to IF -:eth2:-
[root@dell4-4 system]# ifconfig eth2.100 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.200 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br100
[root@dell4-4 system]# brctl addif br100 eth1.100
[root@dell4-4 system]# brctl addif br100 eth2.100
[root@dell4-4 system]# ifconfig br100 up
[root@dell4-4 system]# brctl addbr br200
[root@dell4-4 system]# brctl addif br200 eth1.200
[root@dell4-4 system]# brctl addif br200 eth2.200
[root@dell4-4 system]# ifconfig br200 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br100 8000.0002b3109b8a no eth1.100
eth2.100
br200 8000.0002b3109b8a no eth1.200
eth2.200
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# brctl showmacs br100
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:0a:e4:83:89:07 no 0.19
2 00:0b:5f:54:de:81 no 0.91
2 00:e0:ed:0f:72:86 no 1.28
[root@dell4-4 system]# brctl showmacs br200
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:0a:e4:83:89:07 no 1.14
2 00:0b:5f:54:de:81 no 1.87
1 00:e0:ed:0f:72:86 no 0.24
[root@dell4-4 system]# tc qdisc add dev eth1.100 root netem delay 100ms
[root@dell4-4 system]#
======================================================================
Some sample tc command lines controlling netem and its impairments
are given below.
tc qdisc add dev eth1.100 root netem loss 0%
tc qdisc add dev eth1.200 root netem loss 0%
tc qdisc add dev eth1.300 root netem loss 0%
tc qdisc add dev eth1.400 root netem loss 0%
Add delay and delay variation:
tc qdisc change dev eth1.100 root netem delay 100ms 50ms
tc qdisc change dev eth1.200 root netem delay 100ms 50ms
tc qdisc change dev eth1.300 root netem delay 100ms 50ms
tc qdisc change dev eth1.400 root netem delay 100ms 50ms
Add delay, delay variation, and loss:
tc qdisc change dev eth1 root netem delay 2000ms 1000ms loss 10%
=====================================================================
12. References
12.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330, May
May 1998. 1998.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. November 2002.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
skipping to change at page 25, line 21 skipping to change at page 28, line 9
BCP 176, RFC 6576, March 2012. BCP 176, RFC 6576, March 2012.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012. RFC 6703, August 2012.
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results Supporting Advancement of RFC 2679 on the Plan and Results Supporting Advancement of RFC 2679 on the
Standards Track", RFC 6808, December 2012. Standards Track", RFC 6808, December 2012.
11.2. Informative References 12.2. Informative References
[ADK] Scholz, F. and M. Stephens, "K-sample Anderson-Darling [ADK] Scholz, F. and M. Stephens, "K-sample Anderson-Darling
Tests of Fit, for Continuous and Discrete cases", Tests of Fit, for Continuous and Discrete cases",
University of Washington, Technical Report No. 81, University of Washington, Technical Report No. 81, May
May 1986. 1986.
[Fedora] "http://fedoraproject.org/". [Fedora] "http://fedoraproject.org/", .
[I-D.morton-ippm-2680-bis] [I-D.morton-ippm-2680-bis]
Almes, G., Zekauskas, M., and A. Morton, "A One-Way Loss Almes, G., Zekauskas, M., and A. Morton, "A One-Way Loss
Metric for IPPM", draft-morton-ippm-2680-bis-01 (work in Metric for IPPM", draft-morton-ippm-2680-bis-02 (work in
progress), August 2013. progress), February 2014.
[I-D.morton-ippm-advance-metrics] [I-D.morton-ippm-advance-metrics]
Morton, A., "Lab Test Results for Advancing Metrics on the Morton, A., "Lab Test Results for Advancing Metrics on the
Standards Track", draft-morton-ippm-advance-metrics-02 Standards Track", draft-morton-ippm-advance-metrics-02
(work in progress), October 2010. (work in progress), October 2010.
[Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren", [Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren",
published by ITG Fachgruppe, 2nd meeting 5.2.3 (NGN) http: published by ITG Fachgruppe, 2nd meeting 5.2.3 (NGN)
//www.itg523.de/oeffentlich/01nov/ http://www.itg523.de/oeffentlich/01nov/
Heidemann_QOS_Messverfahren.pdf , November 2001. Heidemann_QOS_Messverfahren.pdf , November 2001.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[Radgof] Bellosta, C., "ADGofTest: Anderson-Darling Goodness-of-Fit [Radgof] Bellosta, C., "ADGofTest: Anderson-Darling Goodness-of-Fit
Test. R package version 0.3.", http://cran.r-project.org/ Test. R package version 0.3.", http://cran.r-project.org/
web/packages/ADGofTest/index.html, December 2011. web/packages/ADGofTest/index.html, December 2011.
[Radk] Scholz, F., "adk: Anderson-Darling K-Sample Test and [Radk] Scholz, F., "adk: Anderson-Darling K-Sample Test and
Combinations of Such Tests. R package version 1.0.", , Combinations of Such Tests. R package version 1.0.", ,
2008. 2008.
[Rtool] R Development Core Team, "R: A language and environment [Rtool] R Development Core Team, , "R: A language and environment
for statistical computing. R Foundation for Statistical for statistical computing. R Foundation for Statistical
Computing, Vienna, Austria. ISBN 3-900051-07-0, URL Computing, Vienna, Austria. ISBN 3-900051-07-0, URL
http://www.R-project.org/", , 2011. http://www.R-project.org/", , 2011.
[WIPM] "AT&T Global IP Network", [WIPM] "AT&T Global IP Network",
http://ipnetwork.bgtmo.ip.att.net/pws/index.html, 2012. http://ipnetwork.bgtmo.ip.att.net/pws/index.html, 2012.
[mii-tool] [mii-tool]
"http://man7.org/linux/man-pages/man8/mii-tool.8.html". "http://man7.org/linux/man-pages/man8/mii-tool.8.html", .
[netem] "http://www.linuxfoundation.org/collaborate/workgroups/ [netem] "http://www.linuxfoundation.org/collaborate/workgroups/
networking/netem". networking/netem", .
Authors' Addresses Authors' Addresses
Len Ciavattone Len Ciavattone
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420 1239 Phone: +1 732 420 1239
Fax:
Email: lencia@att.com Email: lencia@att.com
URI:
Ruediger Geib Ruediger Geib
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt, 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 58 12747 Phone: +49 6151 58 12747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/ URI: http://home.comcast.net/~acmacm/
skipping to change at page 27, line 17 skipping to change at page 29, line 44
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/ URI: http://home.comcast.net/~acmacm/
Matthias Wieser Matthias Wieser
Technical University Darmstadt Technical University Darmstadt
Darmstadt, Darmstadt
Germany Germany
Phone:
Email: matthias_michael.wieser@stud.tu-darmstadt.de Email: matthias_michael.wieser@stud.tu-darmstadt.de
 End of changes. 36 change blocks. 
74 lines changed or deleted 202 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/