RE: [bmwg] RFC 2889, Appendix A

["Jerry Perser" <jerry at perser.org>]

Comments inline:

> * The formulas are incomplete.  The TXTIME formulas has no numerator.
> (I'm guessing this is a known bug)

Your right.  Somehow a line got deleted and no one noticed. The formula
should read:

            [ BURST * (IFG + 64 + 8*LENGTH) ] - IFG
  TXTIME = ------------------------------------------
                            SPEED

> * The included example doesn't agree with the IBG formula

The problem is I took the equations from Sprient's Advance Switch Test
application.  I don't have access to the source code (anymore), so I can't
verify if Sprient's application is "a mess".  When I added the appendix, I
just verified that the equations matched the test we were running at the
time.

> Anyway this leads me to the question:  What is the IBG supposed to be?
> 
> Does the IBG contain the IFG + extra?  Or is the IBG seperate from the
> IFG?
>
> Put another way:  At 100% load is my IBG supposed to equal the IFG? (RFC
> formula)
> or does it equal 0? (RFC example)

RFC 2285, section 3.4.3 does not specify.  Could you look at the design
specification for the ML7710 and let us know what was implemented?  I am
also curious what IXIA implemented.  I put the equations in the RFC so both
companies could implement the same measurement.

> 
> * (NIT) The range for LOAD in the IBG equation should be written as (0,
> 100] since 0 makes the equation nonsensical, i.e. you can't divide by 0
> (again, this is obvious, or at least should be)

You must have come from a computer science school.  Those guys/gals forget
to divide by zero because of the stupid microprocessor.  We electrical
engineers are not bound by the microprocessor's math functions and learned
to divide by zero during Calculus I.

The reason zero was included is that zero is a valid offered load.  It is
not used very often, but still valid.  "nonsensical" is a claim of value,
not a claim of fact.  Fact: If you set the offered load to zero, then the
time between burst of frames becomes very large (or plus infinity).

I don't recommend testing with an offered load of zero, but that doesn't
change the fact that zero is a member of the set of all valid offered loads.
As part of the QA process in the early days of Spirent, we would set the
offered load to zero to make sure the applications did not crash.
 
> * (NIT) Giving results in seconds seems silly when the Ethernet transmit
> clock is +/- 100 ppm.  Bit times would at least be accurate.

Claim of policy, not claim of fact.  I find it offensive when the 802.3
people think that they are the only interface that matters.  I know you
didn't mean to offend, so I won't personal attack you.  Instead, I will
disagree with your statement that bit times +/- 100 ppm is more accurate
than seconds +/- 0 ppm.

Between all the different interface types and encoding format, I found that
the unit of second was common.  I also found that every one of those
Engineers were able to convert to the unit that mattered to them.  Did you
have any difficultly converting seconds in to 802.3 bit times?

While Ethernet 802.3 uses MFM, 4b/5b, and 8b/10b encoding, other
technologies may not.  The thing common about MFM, 4b/5b, and 8b/10b
encoding is that that all have a fixed number of bits per unit of time.
Other encoding like RLL (Run Length Limited) or FEC (Forward Error
Correction) do not.  In these encoding a bit time depends upon the sequence
of data and is not fixed.

Also consider PPP Bit-Stuffing and POS Byte-Stuffing.  They change the
meaning if bit time.  RFC 4814 section 5 has an excellent description of the
problem and suggest you read it.

Jerry Perser

P.S.

Try not to use acronyms like PPM.  I was chastised on this reflector several
years ago by a brilliant programmer for using it.  It made no sense to her
why I was using Packets Per Minute.  Notice that RFC 2889 no longer uses
that acronym.


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.30/1126 - Release Date: 11/12/2007
12:56 PM
 


_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg