Subject: [bmwg] New version of the IPv6 Benchmarking draft

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Fri, 9 Jun 2006 01:08:05 -0400

Dear BMWG members,
 
Please find posted the new version of the IPv6 Benchmarking draft that
incorporates the comments received from the work group on version -00
(actions taken are also listed):   
 
http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.t
xt
 
We would highly appreciate your comments and recommendations on this
version of the draft. We hope this version will receive the support of
the WG, at the IETF 66 meeting, to become a workgroup document. There is
a great need for IPv6 benchmarking recommendations driven by its market
adoption so we hope this work done within the BMWG will address this
need. Thank you for your review and support. 
 
Best Regards,
Ciprian Popoviciu
for the draft authors
 
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------
 
1. Refer to RFC 1242 for terminology
 
- DONE. We believe that this draft does not require a new, technology
specific, document.
 
2. Remove Section 3
 
- DONE

3. Rewrite section 4 and refer to DUT setup section in 2544 for Topology

- DONE

4. Rewrite section 5.1 and refer to formula for calculating throughput
and add appendix where applicable (use same numbers as in RFC 2544 and
document EH expected  Perf. numbers 
 
- DONE. We added an appendix listing the throughput formula for Ethernet
(RFC 2544 is referenced for the actual numbers) and the formulas for
SONET along with the calculated numbers. We also added a statement
indicating that the a given frame size includes any EH that is used
during test.

5. Request to IANA to allocate Ipv6 addresses to BMWG for Ipv6
benchmarking (similar to 192.18.0.0 in RFC 3330)
 
- DONE

6. Revisit section 5.3 to include router behavior in the presence of
Hop-by-Hop EH
 
- We would like to provide an explanation for choosing not to include
the Hop-by-Hop EH in the recommended test traffic. 
 
The concept of extension headers was introduced in IPv6 with the intent
of providing protocol extensibility mechanisms similar to the IPv4
Options but with a lesser impact on the intermediary network nodes that
in most cases do not need to be aware of the information carried in
these headers. Routers might be required, in support of a service such
as Mobility for example, to process fully an EH but for the most part
they must consider the extension headers as part of the payload.
Performing benchmarking tests on IPv6 without evaluating the DUT
capability to process extension headers is similar to RFC 2544 not
focusing on IPv4 traffic with options. This is practical considering the
most common forwarding cases and the fact that options lead to a very
large number of possible scenarios.
 
In IPv6 however we have a special case. If we require the router to look
at upper layer information (inside of the payload), then the router must
hop, one-by-one, across the entire EH chain until it reaches the upper
layer header. In the process, the router does not analyze the
information carried by the EH, it is interested only in the Next Header
field and the header length. Nevertheless, this process can have an
impact on forwarding performance and it would happen in the case of
rather common traffic. For this reason we specifically recommend the
tester to use traffic with a chain of extension headers and to apply
filters that force the router to look at upper layer information and
thus to hop the chain.
 
The Hop-by-Hop header is special because it is in a way very much
similar to the IPv4 Options, it forces the intermediary network devices
to process it. We do not recommend the use of IPv6 traffic with
Hop-by-Hop header because the tests will be equivalent with testing
forwarding of IPv4 traffic with Options. It would evaluate the control
plane and not the data plane capabilities of the DUT. The inclusion of
the Hop-by-Hop EH in the EH chain of the test traffic would stop the
tester from analyzing the behavior mentioned in the previous paragraph.
Moreover, the use of Hop-by-Hop EH is very limited and often times such
traffic is terminated by the router itself and not forwarded (as is the
case of Router Alert with MLD). For these reasons, we decided to exclude
the Hop-by-Hop EH from the benchmarking tests. On the other hand, it
could be very well used for conformance and functionality tests.
 
The ESP EH is also excluded from these recommendations. In the presence
of such an EH, the payload of the IPv6 packet would be encrypted so the
upper layer information (and some extension headers) would not be
visible to the router. So the scenario described two paragraphs earlier
would not be possible to test since the upper layer information filters
would not work. The router would view all extension headers as part of
the payload so their existence would be irrelevant as far as forwarding
is concerned.

7. Remove IMIX reference - not ready to address it at this stage 
 
- DONE

8. EH- test individually and combinations of EH 
 
- In its current form, this document still recommends the use of a
combination of EH for testing and does not address the case of traffic
with individual extension headers. This is due to the fact that we are
not focusing on the router's ability to fully process the various EH
types but rather its ability to forward traffic with EH where the EH
structure and content is not relevant to the forwarding node. This is
the most likely operational mode for network devices forwarding IPv6
traffic. A study of routers processing IPv6 extension headers would be
similar to a study of routers processing IPv4 options. The IPv6 EH
concept was introduced in order to avoid the burden of handling options
and that is the way we look at this problem. With modifiers, such as
filters that analyze the upper layer information, the routers are still
required to do some EH processing which is: hop one by one across the EH
chain until reaching the upper layer information. The performance impact
of this process is what we wanted to make sure gets evaluated since it
is today and will be in the future a very likely operational scenario.

9. Test Ipv4 only, Ipv6 only then Dual stack ?? 
 
- DONE. We made recommendations for the mix of IPv4 and IPv6 traffic. We
would appreciate your opinion on the selected numbers.

10. Remove measuring LC CPU /Memory usage data - can not be used to
compare products ??
 
- We removed the strict requirements in the original version. We kept a
general recommendation for platform parameters (the relevant ones to
each platform and architecture) monitoring since we believe that such
data can be very informative with respect to the behavior of the DUT. As
an example, under certain conditions the DUT might switch from a
Hardware Forwarding path to a Software Forwarding path thus taxing
resources used for control plane functions. The impact might not be
observed in terms of forwarding performance but might put the devices in
a state where it operate outside the acceptable operational limits (as
an example, the CPU might be above the 60% operational expectation of
some Service Providers).
 
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------
 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg