15 Aug 2006 01:09

### Help with draft-ietf-bmwg-hash-stuffing-05, 5.2.1. Calculating Bit-Stuffing Probability

```Could you expand on how a transition matrix works in section 5.2.1?  I'm not
a probability expert, but I keep getting a different answer than stated.

I am using Boolean logic to work out the probability.  Looking at the
diagram, I see 5 decisions between start and state 5.  It's not clear if the
bit stuffing happens in state 5 or after state 5.  Could this be clarified?
Each decision represents a bit.  So we have either 5 or 6 bits that get
stuffed to 6 or 7 bits.  I'll assume 6 bits because it's closer to the
drafts solution.

With 6 bits there are 64 possible combinations (2 ** 6).  It appears that
only one combination creates the bit stuffing, which is 111111.  So the
solution I come up with every time is 1 out of 64 or 1/64.  I have no idea
how to get 1/62.

Jerry Perser
Veriwave
Main :  818-338-4000
Direct: 818-338-4112
Fax:    818-338-4005
```
15 Aug 2006 15:34

```BMWG,

At our last meeting, we observed that recent readership
on various work items was somewhat light, so let me make
a general call to the WG to read our drafts and share your

A few have shared their reviews, and we are awaiting
many more.  From the minutes:

>The volunteers and their Review Areas are listed below:
>
>Hash and Stuffing:  Diego Dugatkin and Jerry Perser
>IPsec:              Jason Guy and Scott Poretsky
>Accelerated Stress: Scott Bradner, Jay Karthik, Chip Popoviciu, and
>                     Jerry Perser
>Protection:         (All the people who committed to review on the list!)

Al
bmwg co-chair
```
15 Aug 2006 16:43

### RE: Help with draft-ietf-bmwg-hash-stuffing-05, 5.2.1. Calculating Bit-Stuffing Probability

```
> -----Original Message-----
> From: Jerry Perser [mailto:jperser <at> veriwave.com]
> Sent: Monday, August 14, 2006 7:09 PM
> To: bmwg <at> ietf.org
> Subject: [bmwg] Help with
> draft-ietf-bmwg-hash-stuffing-05,5.2.1. Calculating
> Bit-Stuffing Probability
>
> Could you expand on how a transition matrix works in section
> 5.2.1?  I'm not a probability expert, but I keep getting a
>
Sure.  However, others people's examples would probably be
explanations of "Markov chains."

http://mathworld.wolfram.com/MarkovChain.html
http://en.wikipedia.org/wiki/Examples_of_Markov_chains

> I am using Boolean logic to work out the probability.
> Looking at the diagram, I see 5 decisions between start and
> state 5.  It's not clear if the bit stuffing happens in state
> 5 or after state 5.  Could this be clarified?
> Each decision represents a bit.  So we have either 5 or 6
> bits that get stuffed to 6 or 7 bits.  I'll assume 6 bits
> because it's closer to the drafts solution.
>
The draft states that a bit is stuffed if and only if state 5 is
reached,
```

20 Aug 2006 00:23

### RE: IPv6 Benchmarking

```
NOTE: Cross posting this discussion of the IPv6 Benchmarking draft
(http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.
txt) to the v6ops and bmwg aliases as this is a topic of interest to
both work groups. Feedback is very welcomed!

------------------------------------------------------------------------
----------------------------------------------

Bill,

I appreciate the fact that you shared with us this particular reference.
It is an excellent example that supports our decision to include in the
IPv6 Benchmarking draft the scenario of evaluating the performance of
processing traffic with extension headers (section 4.3) while filters
for upper layer protocols are applied (section 5.2.2). Such benchmarking
tests could uncover the fact that the DUT either is not processing such
traffic correctly or that its forwarding performance is significantly
impacted under such circumstances. Both these situations would be
critical data points in the process of evaluating networking equipment.

Thank you again for your valuable comments and suggestions below and we
hope you will continue to help us improve this draft.

Best Regards,
Chip

-----Original Message-----
From: Bill Cerveny [mailto:bill <at> wjcerveny.com]
Sent: Thursday, August 17, 2006 6:30 PM
```

25 Aug 2006 22:20

### Proposal on IPv6 Benchmarking

```BMWG,

The proponents of IPv6 Benchmarking have prepared a description of
their work effort in the form of a proposal, below.

BMWG discussed this work at the Montreal IETF-66 session,
where there was strong support and involved membership
(see meeting minutes). The related I-D can be found here:
http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.txt

Please weigh-in on whether this topic/draft should become part
of BMWG's chartered work, by

September 25, 2006

And, if you support the work, please say:

+  HOW you intend to support the development in BMWG,
(by reviewing draft X by MM/DD/YY, for example),  or

+  WHY this work will be beneficial to BMWG's user community, or

+  Modifications that would make the proposal more useful
(which we will discuss on the list), and

+  (anything else that's constructive)

And remember, we'd like to hear your opinion on the list,
even if you spoke in favor of this proposal at the meeting.

```

25 Aug 2006 23:12

### RE: Proposal on IPv6 Benchmarking

```Al & BMWG,

I am in support of this work becoming BMWG chartered work. I belive that
draft will be very beneficial to BMWG user community as well as broader
audience as there needs to be standardized way to evaluate and compare
performance capabilities of v6 devices and this draft is addressing
exactly that.

I will support it by reviewing the
draft:draft-popoviciu-bmwg-ipv6benchmarking-01.txt by 09/20/06 as well
as draft-popoviciu-bmwg-ipv6benchmarking-02.txt when it becomes
available.

Thx,

Silvija

-----Original Message-----
From: Al Morton [mailto:acmorton <at> att.com]
Sent: Friday, August 25, 2006 4:20 PM
To: bmwg <at> ietf.org
Cc: Dan Romascanu
Subject: [bmwg] Proposal on IPv6 Benchmarking

BMWG,

The proponents of IPv6 Benchmarking have prepared a description of their
work effort in the form of a proposal, below.

BMWG discussed this work at the Montreal IETF-66 session, where there
```

26 Aug 2006 16:12

### RE: Proposal on IPv6 Benchmarking

```Hi Al and fellow BMWG folks,

I will review this work by September 20, 2006.

This is a good time for a benchmarking draft for IPv6, as it appears the technology is finally gaining
serious mindshare in circles outside the IETF. To move forward for IPv6 deployments we need a methodology
for comparing the most basic forms of use from the various vendor options.

Regards,

--
Aamer Akhter / aa <at> cisco.com
Ent & Commercial Systems, cisco Systems

>  -----Original Message-----
>  From: Al Morton [mailto:acmorton <at> att.com]
>  Sent: Friday, August 25, 2006 4:20 PM
>  To: bmwg <at> ietf.org
>  Cc: Dan Romascanu
>  Subject: [bmwg] Proposal on IPv6 Benchmarking
>
>  BMWG,
>
>  The proponents of IPv6 Benchmarking have prepared a description of
>  their work effort in the form of a proposal, below.
>
>  BMWG discussed this work at the Montreal IETF-66 session,
>  where there was strong support and involved membership
>  (see meeting minutes). The related I-D can be found here:
>  http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-
```

27 Aug 2006 16:28

### Re: Proposal on IPv6 Benchmarking

```Al and BMWG,

I would be able to help with refining the IPv6 benchmarking document via
ongoing document review and contributing with additional content, if
merited.

A document providing guidance in the area of IPv6 benchmarking would be
welcome to organizations (including the US federal agencies mandated to
deploy IPv6 on their backbone networks) attempting to understand why and
how network device IPv6 performance must be tested. A document that
attempts to define which areas need to considered and which describes
how to test/benchmark these areas may be well received.

Regards,

Bill Cerveny

Al Morton wrote:
> BMWG,
>
> The proponents of IPv6 Benchmarking have prepared a description of
> their work effort in the form of a proposal, below.
>
> BMWG discussed this work at the Montreal IETF-66 session,
> where there was strong support and involved membership
> (see meeting minutes). The related I-D can be found here:
> http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.txt
>
>
> Please weigh-in on whether this topic/draft should become part
```

28 Aug 2006 11:33

### Re: FW: [6net technical-leaders] FW: Proposal on IPv6 Benchmarking

```Hi,

I fully support this draft to make it part of BMWG's chartered work. There's
a strong need in the field for consistency in this area as more and more vendors
are making serious efforts to position IPv6.

I will review draft 01 before 9/9/2006 and will provide comments where needed.

>
> -----Original Message-----
> From: Al Morton [mailto:acmorton <at> att.com]
> Sent: Friday, August 25, 2006 10:20 PM
> To: bmwg <at> ietf.org
> Cc: Dan Romascanu
> Subject: [bmwg] Proposal on IPv6 Benchmarking
>
> BMWG,
>
> The proponents of IPv6 Benchmarking have prepared a description of their
> work effort in the form of a proposal, below.
>
> BMWG discussed this work at the Montreal IETF-66 session, where there
> was strong support and involved membership (see meeting minutes). The
> related I-D can be found here:
> http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.t
> xt
>
> Please weigh-in on whether this topic/draft should become part of BMWG's
> chartered work, by
>
```

29 Aug 2006 03:54

### RE: WG Last Call on Accelerated Stress Benchmarking Drafts

```Hello Authors,

with my comments on the methodology draft shortly.

Most of the comments are just nits.

- Introduction : "faster test duration" could be replaced by "shorter
test duration"

- Introduction :  "Multiple benchmarks are made for each Benchmark Plane
during each Phase."  I suggest replacing 'made' with 'proposed' or
'suggested'.

- Need to fix "These benchmarks White Box benchmarks ..... " in
Introduction.

- The white box benchmarks could be a very important for many and I
recommend adding the CPU Utilization and Available Memory benchmarks to
Table 1 for all 3 phases.

- 3.1.2 Configuration Sets. We should mention forwarding rate, besides
feature and scaling limit in the definition of the term.

- I am wondering if we need a new term called "Peak Load" or something
else to indicate this, which is basically to denote a sample
configuration set beyond which the device under test becomes unusable or
unresponsive to any command line instruction. If you decide to add this,
another usual term would be "duration of unresponsiveness" which should
be ideally 0.
```