Jerry Perser | 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.

Please help me.

Jerry Perser
Veriwave
Main :  818-338-4000
Direct: 818-338-4112
Fax:    818-338-4005
Al Morton | 15 Aug 2006 15:34
Picon
Favicon

Summer Reading...

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
comments on the list.

In addition, several people volunteered to read specific drafts.
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
Player, Timmons | 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 
> different answer than stated.
>
Sure.  However, others people's examples would probably be
better.  Please check out the following links for
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,
(Continue reading)

Chip Popoviciu (cpopovic | 20 Aug 2006 00:23
Picon
Favicon

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
(Continue reading)

Al Morton | 25 Aug 2006 22:20
Picon
Favicon

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.

(Continue reading)

Silvija Andrijic Dry (sdry | 25 Aug 2006 23:12
Picon
Favicon

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
(Continue reading)

Aamer Akhter (aakhter | 26 Aug 2006 16:12
Picon
Favicon

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-
(Continue reading)

Bill Cerveny | 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
(Continue reading)

Sven Lanckmans | 28 Aug 2006 11:33
Picon
Favicon

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
>
(Continue reading)

Jay Karthik (jakarthi | 29 Aug 2006 03:54
Picon
Favicon

RE: WG Last Call on Accelerated Stress Benchmarking Drafts

Hello Authors,

I had the following comments on the terminology ID. I will follow up
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.
(Continue reading)


Gmane