Subject: [bmwg] RFC 2889, Appendix A

From: "Timmons C. Player" <[email-masked]>
Date: Wed, 07 Nov 2007 14:51:51 -0500

Howdy, all

So. I've been working through Appendix A of RFC 2889, and no offense to
anyone, but it's a mess.

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

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

According to the RFC,

         [(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
   IBG = -----------------------------------------------------------
                                  SPEED

Now, try the example:

   Example:

     LENGTH   = 64  bytes per frame
     LOAD     = 100 % offered load
     BURST    = 24  frames per burst
     SPEED    = 10  Mbits/sec (Ethernet)
     DURATION = 10  seconds test

you get IBG = IFG

I guess this makes sense for 100% load.  But given the answers in the
example, I think the load is supposed to be 50%.  However, even with 50%
load, the RFC formula gives IBG = 1622.4 microseconds which is off by 1
IFG from the example:

1622.4 micro - 9.6 micro = 1612.8 micro

This suggests that the example is using

        [(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)]
   IBG = -----------------------------------------------------------
                                  SPEED

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)

Personally, I'm thinking that the IBG is really IFG + extra and that the
formulas  in the RFC should be:

         [(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
   IBG = -----------------------------------------------------------
                                  SPEED

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

This means that for 50% load, the example values would have the
following answers:

IBG = 1622.4 micro (instead of 1612.8 micro)
TXTIME = 1603.2 micro
#OFBURSTS = 3101 (instead of 3110)

Or did I miss something?

* (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)

* (NIT) Giving results in seconds seems silly when the Ethernet transmit
clock is +/- 100 ppm.  Bit times would at least be accurate.

Timmons

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

---

From: Al Morton <[email-masked]>
Date: Wed, 07 Nov 2007 14:56:35 -0500

Hi Timmons,

There's no Errata for 2889, care to go that route?
I think you just started the process...

Al

At 02:51 PM 11/7/2007, Timmons C. Player wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Howdy, all
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (MingW32)
>
>iD8DBQFHMhdXPps6tU0vhXERAlQuAJ48LW0oS8KLY4XFxln61eA2hsfdEQCdHkeE
>HNA8nXCkMF5RmeZAbdFT6FQ=
>=AgJH
>-----END PGP SIGNATURE-----
>

---

From: "Jerry Perser" <[email-masked]>
Date: Mon, 12 Nov 2007 12:07:22 -0800

> (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.

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

> (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.
 
> 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

---

From: "Timmons C. Player" <[email-masked]>
Date: Wed, 14 Nov 2007 10:45:43 -0500

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

In addition to adding the formula above to the Errata Al mentioned, I'd
like to suggest making the following change as well.  In stead of reading:

   Example:

    IBG       = 1612.8 uS
      TXTIME    = 1603.2 uS
    #OFBURSTS = 3110

I think it should read:

   Example:

     LOAD     = 50 % offered load

    IBG       = 1622.4 uS
    TXTIME    = 1603.2 uS
    #OFBURSTS = 3101

> RFC 2285, section 3.4.3 does not specify.  
> 
Hmm...  Well, I guess it doesn't really matter so long as the formula
for IBG and TXTIME are consistent.  In any case, the corrected TXTIME
formula and existing IBG formula make it clear that the IBG contains the
IFG since at 100% load, the IBG equals the IFG.

> why I was using Packets Per Minute.  Notice that RFC 2889 no longer uses
Noted.  Explaining your TLAs (Three Letter Acronyms) is always a good
idea. :)

---

From: "John Dawson" <[email-masked]>
Date: Wed, 14 Nov 2007 12:40:12 -0600

Example:

You can not include the term "offered load" in your equation, as
"Offered Load" is a measured quantity.
I believe the proper terminology for this situation would be "intended
load".

John D.