Re: Ideally BER should be a customer controlled option
- To: <bill.st.arnaud@xxxxxxxxxx>, "Rich Seifert" <seifert@xxxxxxxxxx>, "Jaime Kardontchik" <kardontchik.jaime@xxxxxxxxxxx>, "Chang, Edward S" <Edward.Chang@xxxxxxxxxx>, <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
- Subject: Re: Ideally BER should be a customer controlled option
- From: "Khaled Amer" <khaledamer@xxxxxxx>
- Date: Tue, 1 Jun 1999 09:12:57 -0500
- References: <NBBBJIMEPHPGCNGAHPMFIEMOEMAA.bill.st.arnaud@xxxxxxxxxx>
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
I beg to disagree with you on this ...
I believe that the physical medium should provide the lowest BER rate that
is feasible, and meets most of the customer requirements. I agree with the
comment made by Rich Seifert:
'Users have enough "dials to twiddle" that can screw up their networks
configurable physical channel behavior'
TCP retransmissions should be mostly due to other factors including
congestion, flow control, buffer overflows, ...etc. I do not believe that
the BER should be made as a factor to 'deliberately increase' the
retransmissions of TCP as needed.
----- Original Message -----
From: Bill St. Arnaud <bill.st.arnaud@xxxxxxxxxx>
To: Rich Seifert <seifert@xxxxxxxxxx>; Jaime Kardontchik
<kardontchik.jaime@xxxxxxxxxxx>; Chang, Edward S <Edward.Chang@xxxxxxxxxx>;
Sent: Sunday, May 30, 1999 7:29 PM
Subject: Ideally BER should be a customer controlled option
Realizing that there are some practical limitations, as much as possible,
BER should be a customer controlled option.
If I am running only IP with high number of a TCP transmissions I may
deliberately want a high BER to act as layer 1 WRED. Also I may be able to
push my repeater distance using low cost laser and a willing to suffer a
If I am running some other protocol I may require a lower BER.
I always believe in giving the customer as much choice as possible. I don't
we should play god and decide before hand what is the best BER for our
Bill St Arnaud
Director Network Projects
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Rich
> Sent: Friday, May 28, 1999 2:53 PM
> To: Jaime Kardontchik; Chang, Edward S;
> Subject: Re: 1000BASE-T PCS question
> At 9:11 AM -0700 5/27/99, Jaime Kardontchik wrote:
> >My impression is that it would have been much more simpler if
> the group had
> >been called "10-Gigabit-Ethernet" instead of "Higher-Speed
> Group". At some
> >time in the future the group will have to decide what kind of
> standard to work
> Well, it was not clear at all (and still is not clear) that a
> single-speed of
> 10 Gb/s is the goal of all of the study group members, or indeed reflects
> the needs of the user community. It is one of the purposes of the Study
> Group to determine what speed(s) should be supported in a standard.
> >Ethernet standards deliver a BER of 10^(-10).
> This is simply not true. The BER spec for 10BASE5 is 10^-9. For
> 10BASE2 and
> 10BASE-T, it is 10^-8. For 100BASE-X and 1000BASE-X, it is 10^-12.
> The BER goals for any higher-speed standard should be determined
> by the SG.
> Further, BER is really a parameter more relevant to serial transmission
> systems that do not use any block-coding; in such systems it is
> straightforward to map between the BER and the Frame Loss Rate (a more
> significant parameter in a connectionless, best-effort frame delivery
> system). We had long discussions both in Fast Ethernet and
> 1000BASE-T about
> how many frame errors are generated by a single bit error, the
> between symbol errors and bit errors, etc. In the end, the only observable
> characteristic at the MAC service interface is the Frame Loss Rate. I
> propose that any future standards work use this parameter to characterize
> the error performance of the system, rather than BER.
> Rich Seifert Networks and Communications Consulting
> seifert@xxxxxxxxxx 21885 Bear Creek Way
> (408) 395-5700 Los Gatos, CA 95033
> (408) 395-1966 FAX
> "... specialists in Local Area Networks and Data Communications systems"