Subject: [bmwg] feedback on hash/stuffing ID

From: David Newman <[email-masked]>
Date: Sun, 15 Aug 2004 14:04:01 -0700 (PDT)

Thanks very much for the positive reception to the hash and stuffing ID
in San Diego.

Here, in something approximating random order, are the changes suggested 
since draft 00's release along with our responses.

1. Change references from "random" to "uniform" distribution (with 
possible future vectors for Poisson or other distributions).

Our take: We agree.

2. In section 4, characterize the degree of randomness in the
pseudorandom number generator.

Our take: We agree, and would welcome suggested strawman language for
this section.

3. In section 4, describe the pseudorandom number generator algorithm.

Our take: We might agree, provided this is a high-level description of an 
algorithm and not some code that implementers must use. This is consistent 
with much previous IETF work leaving implementation up to the 
implementers.

4. In section 4.2, change Ethernet address format to:

RR & 0xFE : PP : PP : RR : RR : RR

This gets us away from static OUIs in Ethernet addresses while
preventing the accidental introduction of the Ethernet multicast
address.

Our take: We agree.

5. In section 4.3, expand discussion on "even" distribution across IP
paths. At an absolute minimum, the discussion should define or rename
"even."

Our take: We agree. The intent was to ensure uniform distribution, as
noted on point 1 above, but more specificity is needed.

6. In section 4.2, distinguish between L2 types and add a section on
MPLS label hashing.

Our take: We agree, and would welcome suggested strawman language for
this section.

We would also like input on experiences with hashing on L2 technologies
other than MPLS.

7. In section 4.3, add section on link aggregation done using L3
criteria. (Cisco's L3 Etherchannel is one proprietary example; there are
others from Juniper, Avici, et al).

Our take: We agree, and would welcome suggested strawman language for
this section.

Further, we would be interested in hearing of any other scenarios for
which IP address hashing is relevant.

8. Divide the ID into separate terminology and methodology drafts.

Our take: We agree there is merit to a separate track dedicated solely
to measuring the effects of hashing algorithms, and we look forward to
working on that track.

However, we strongly disagree with the suggestion to change the focus of
this ID, on two grounds:

a. A breakup would be orthogonal to the intent of this ID -- namely, to
close two gaping holes in current and pending bmwg methodologies.

For many years, the authors have been asked by vendors to "spoon-feed"
their devices with particular random or nonrandom patterns to ensure
uniform output distributions. A similar problem exists with stuffing.

Current RFCs allow this sort of tuning-for-benchmarks, and that's a
problem we need to address now.

A new terminology/methodology would take longer, and would do nothing to 
address issues with existing methodologies.

b. The bmwg is moving away from the "we've always done it this way"
mentality that allows only terminology or methodology docs.

The bmwg's charter is to make recommendations regarding benchmarking. 
There are cases where those recommendations best take the form of 
"considerations" or "plug-in" documents.

9. Divide the ID into separate documents on hashing and stuffing.

Our take: We agree that separate methodologies for hashing and stuffing
would be merited. We disagree that this ID should be split in two, for
the reasons given for point 8 above.

10. Determine whether (a) the ID should to refer back to existing RFCs
or (b) to modify existing RFCs to reflect the ID's recommendations.

Our take: We lean toward (a) but see pros and cons in both approaches.

The downside for (a) is that novice users of a given RFC may not know to
look further for the hash and stuffing doc. Ergo, (b) would definitely
be the easier path for the user.

(Note, however, that existing RFCs are immutable. A reader coming across
RFC 1944 today would see no warning that it has been obsoleted by RFC
2544.)

The downside for (b) is that the authors/editors of existing RFCs may or 
may not approve of modification and reissue after the fact. In the 
worst-case scenario, authors of some RFCs approve changes and others 
disapprove, with the split dividing perhaps even authors of the same RFC. 
Either way, this would leave us with the same hash and stuffing problems 
we have now. Thus, from a clean-implementation standpoint, (a) is the 
easier path.

As noted, we lean toward (a) but would welcome more discussion, on this
and all other points.

dn/tcp

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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 16 Aug 2004 09:24:29 -0700

>Our take: We agree, and would welcome suggested strawman language for

RFC 1750 is being revised, and the revision is in IETF last call 
right now. See 
<http://www.ietf.org/internet-drafts/draft-eastlake-randomness2-08.txt>, 
and feel free to comment to the Don and IESG if you have any concerns.

This should probably be referenced in any discussion you have on randomness.

>Our take: We might agree, provided this is a high-level description 
>of an algorithm and not some code that implementers must use. This 
>is consistent with much previous IETF work leaving implementation up 
>to the implementers.

See above.

>this ID ...

I agree with David here: keep it as one document.

--Paul Hoffman, Director
--VPN Consortium