Re: IPv6 Benchmarking Draft - Please provide feedback

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 8 Jun 2006, Chip Popoviciu (cpopovic) wrote:
> We would like to ask for your feedback on an "IPv6 Benchmarking" draft
> (attached) we are working on within the Benchmarking Working Group. This
> work was started and is driven by the great demand we see for
> benchmarking guidelines on evaluating the IPv6 performance of network
> devices. This is a subject of great interest to those who deployed or
> consider the deployment of IPv6.
...

Looked pretty good to me.  I think the benchmark should test the 
hop-by-hop (esp router alert) option performance though (see below).

...

==> The document should state in Introduction and perhaps in abstract that
it Updates 2544 (also add that to the header).

4.3.  Traffic with Extension Headers
...
In agreement with RFC2544 omission of tests with
   IPv4 traffic that includes IP options, this document makes no
   benchmarking recommendations for traffic with IPv6 traffic with the
   Hop-by-Hop extension header.

==> Could you clarify what this means?  That these don't need to be
benchmarked and/or the results don't need to be published?

This would be very unfortunate.  In fact, one of the most important
performance tests for a v6 device I'd like to see is how it performs when
receiving forwarded packets with Hop-by-Hop header and either a Router Alert
option or an unknown option (see also the expired
draft-krishnan-ipv6-hopbyhop-00).  Making that a mandatory part
of the test would be a good idea.

   For the most cases, the network elements ignore the EH when
   forwarding IPv6 traffic.  For these reasons it is most likely that
   the EH related performance impact will be observed only when testing
   the DUT with traffic filters that contain matching conditions for the
   upper layer protocol information.

==> hop-by-hop header is unfortunately an exception here, which is why it'd
be very useful to benchmark it.

5.  Modifiers

   RFC2544 underlines the importance of evaluating the performance of
   network elements under certain operational conditions.  The
   conditions defined in RFC2544 Section 11 are common to IPv4 and IPv6
   with the exception of Broadcast Frames.  IPv6 does not use layer 2 or
   layer 3 broadcasts.  This section provides additional conditions that
   are specific to IPv6.

==> so, what is the equivalent test with v6?  All-hosts multicast packets,
something else, or is the test omitted?

The following filter format SHOULD be use for this type
   of evaluation:

==> s/use/used/

7.  IANA Considerations

   IANA SHOULD reserve an IPv6 prefix for benchmarking purposes similar
   to 192.18.0.0 in RFC 3330 [7].

==> you need to give IANA a bit of guidance on which kind of prefix length
you'd want, maybe a /32?.
It's also not clear if IANA has available resources for this:

      "The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:
      0000::/29 - 2001:01F8::/29) is for assignment for testing and
      experimental usage to support activities such as the 6bone, and
      for new approaches like exchanges."
      [RFC2928]

.. but maybe this qualifies under "testing".  In any case, I'd suspect
almost every test could also be done with prefixes from a ULA block so I'd
have a contingency plan ready in case you don't get the allocation from
IANA.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings