Subject: [bmwg] WG Last Call on Address Hash and Bit Stuffing Draft (04)

From: Al Morton <[email-masked]>
Date: Fri, 06 Jan 2006 09:26:33 -0500

BMWG:

A WG Last Call period for the Internet-Draft on

"Hash and Stuffing: Overlooked Factors in Network Device Benchmarking"
                   <draft-ietf-bmwg-hash-stuffing-04.txt>

will be open from 6 Jan 2006 through 3 Feb 2006.

A URL for this Internet-Draft is:
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bmwg-hash-stuffing-04.txt

Version 04 (and version 03) incorporates minor changes
(change logs have been published on the mailing list).
The authors believe that all comments from the working group
have been addressed, dating back to July 2004 when version 00
was published.

This draft is entering the BMWG Last Call Process. See
http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html
At this time, we are seeking volunteers to complete the
BMWG Last Call Review Template in the message of 4/27/04
titled, "Refinements to the BMWG Last Call Process".
Volunteers should contact [email-masked] and [email-masked]
A copy of the template is available here:
http://home.comcast.net/~acmacm/IDcheck/LastCallTemplate.txt

Whether or not you decide to volunteer for the directed review,
please *read* and express your opinion on whether or not this
Internet-Draft should be given to the Area Directors for
consideration as an Informational RFC.  Send your comments
to this list or [email-masked] and [email-masked]

Kevin, Al
BMWG Co-Chairs 

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Al Morton <[email-masked]>
Date: Wed, 25 Jan 2006 11:40:22 -0500

Hi David and Timmons,

A few comments on the 04 version (as a WG participant).
Also, I've attached a few comments from one of my colleagues,
Len Ciavattone.

hth,
Al

In:
>4.1.  Problem Statement
>
>    The addresses and port numbers used in a test can have a significant
>    impact on metrics such as throughput, jitter, latency, and loss.
>    This is because many network devices feed such addresses into hashing
>    algorithms to determine which path upon which to forward a given
>    packet.
...
(last paragraph)
>    The balance of this section offers recommendations for test traffic
>    patterns, starting at the link layer and working up to the transport
>    layer.  These patterns should overcome the effects of nonrandomness
>    regardless of the hashing algorithms in use.

I thought that a clear(er) statement of the objective of section 4
might be useful to have here (and agree on). So I suggest words to that
affect, something like:

(last paragraph)
Therefore, this memo adds a new consideration for (all?) benchmarking
methodologies, to select address patterns that overcome the effects
of non-randomness regardless of the hashing algorithms in use.  The
balance of this section offers recommendations for test traffic patterns
to avoid these effects, starting at the link layer and working up to the
transport layer.

In 4.2.1, last paragraph:
>    When generating traffic with multiple addresses, it is RECOMMENDED
>    that all addresses use pseudorandom values.  There are multiple ways
>    to use sets of pseudorandom numbers.  One strategy would be for the
>    test instrument to iterate over an array of pseudorandom values
>    rather than incrementing/decrementing from a starting address.  The
>    actual method is an implementation detail; in the end, any method
>    that uses multiple addresses and avoids hash table collisions will be
>    sufficient.

So, it's good to peek inside the black box?  Or is there another way
to ensure that the tester has successfully avoided any affects of
using address patterns that are not quite as random as those
encountered in the real world?

Maybe restate the last sentence something like:
... The actual method is an implementation detail; in the end, any method
that uses multiple addresses and avoids the undesired effects of address
processing in the Device Under Test will be sufficient.

>4.4.  Network-layer Addressing
>
>    Routers make forwarding decisions based on destination network
>    address.  Since there is no hashing of source and destination
>    addresses, the requirement for pseudorandom patterns at the network
>    layer is far less critical than in the Ethernet MAC address case.

The "no hashing" sentence appears a bit too strong, see
the info Len provided in response to this section, below.

If it's acceptable to mention the possible need for Network Layer
Address randomization, then should also mention the special addresses
and ranges to avoid, as in the other sections.

5.2   PPP Bit Stuffing

Len has a comment on the first few paragraphs, below.

Also, it seems possible that the "Type of Service" field
(now the combination of DSCP and ECN bits) has the potential
to produce five 1's in a row. None of the currently assigned
DSCPs/CSs fit the bill, but a precedence of 7 or 3 and the necessary
number of set ToS bits can make five 1's.

A few small clarifications in Section 5.2.1:

because the table is asymmetrical, suggest labeling the header

     \From|
      \   | start     1       2       3       4       5
       \  |
     To \ |
    _____\|_________________________________________________
    start |  0.5  |  0.5  |  0.5  |  0.5  |  0.5  |  0.5
        1 |  0.5  |  0.0  |  0.0  |  0.0  |  0.0  |  0.5
        2 |  0.0  |  0.5  |  0.0  |  0.0  |  0.0  |  0.0
        3 |  0.0  |  0.0  |  0.5  |  0.0  |  0.0  |  0.0
        4 |  0.0  |  0.0  |  0.0  |  0.5  |  0.0  |  0.0
        5 |  0.0  |  0.0  |  0.0  |  0.0  |  0.5  |  0.0

last paragraph, because P(stuff) is used later, suggest defining it here:

    Thus, for an infinitely long string of random bits, the probability
    of 5 sequential 1 bits is

       P(stuff) = P(5 sequential 1 bits) = 1/62.

    Put another way, we expect to add one stuff bit for every 62 bits
    of random uniform data.

In
>5.2.2.  Bit Stuffing for Finite Strings
>
>    The above result indicates that for any string of uniformly
>    distributed random bits, we expect a stuffing event to occur every 62
>    bits.  So, given a ...

suggest the following clarification:
5.2.2.  Bit Stuffing for Finite Strings

    The above result indicates that for any string of uniformly
    distributed random bits, we expect a stuffing event to occur every 62
    bits on average.  So, given a ...

Len's comments follow:

>Subject: FW: [bmwg] WG Last Call on Address Hash and Bit Stuffing  Draft (04)
>Date: Wed, 25 Jan 2006 07:27:27 -0600
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>Thread-Topic: [bmwg] WG Last Call on Address Hash and Bit Stuffing  Draft (04)
>Thread-Index: AcYeCJWUvpEG4GS+SGiHldtLntHmMACGxJpgAE24S/AAFg8moA==
>From: <[email-masked]>
>To: <[email-masked]>
>
>Al,
>I put together a few comments...
>
>Section 4.4, 4.5
>-------------------
>Vendors that support link bundling or composite links (logical links
>formed
>from several physical links) also use network-layer addresses and
>potentially transport-layer port numbers to assign flows to individual
>members. This same flow-based methodology is also used in at least one
>vendor's core router to assign packets to different paths through the
>internal switch fabric.
>
>Also, with regard to address hashing, the entire source and destination
>address are not always used. The specific implementations may only
>utilize
>certain bits in them (to favor one over the other).
>
>
>Section 5.2
>-------------------
>It quotes section 5.2 of RFC1662 as stating that a "0" is inserted prior
>to
>a sequence of 5 contiguous "1" bits. It then says that this is to avoid
>the
>"HDLC control character 0x7D, which contains six "1" bits". In the next
>paragraph it says "Not shown is the 1-byte flag sequence (0x7D)".
>
>Well, in 5.2 of RFC1662 it actually states that a "0" is inserted AFTER
>all
>sequences of 5 contiguous "1" bits. Also, this is done to deal with the
>HDLC
>flag sequence which is 0x7E (01111110) - six "1" bits. There is no
>reference
>to 0x7D under "Bit-stuffed framing" (which is for bit-synchronous links)
>in
>section 5 of that RFC.