Re: [802.3_EPOC] Continuing work on EPOC objectives
I second Mark's comments.
-----Original Message-----
From: Mark Laubach [mailto:laubach@xxxxxxxxxxxx]
Sent: Monday, April 30, 2012 12:32 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Continuing work on EPOC objectives
Marek and all,
Raw performance figures would require an accepted detailed channel model that incorporates the known impairments of concern, a modulation to put under study, and the specific configuration of that modulation that is being put under test. Then, getting to a desired BER will also placing FEC approaches under scrutiny, and likely we'll be talking about interleaver approaches and their performance. The level of detail to get to raw and then to delivered performance figures are both really Task Force items. Otherwise, I agree, it would be nice to see raw now. I just don't see how we can get that now.
I would also point out that selection of modulation, FEC, and interleaver will be a rigorous process for the TF as aggregate processing delays impact round trip time (RTT) and the TF has to take into consideration system impact on EPON scheduling and utilizing full channel capacity under "load" while meeting system performance, e.g. MEF load for businesses, triple play for residential, etc. This implies we need a system load model also that understands EPON's range of upstream packet concatenation sizes under load, as well as effects of PHY operational modes and configurations.
What I would rather suggest we see somewhere in additional objectives is 1) that a common downstream and upstream channel model be created that incorporates impairments, noise, distance, and other requirements as per cable industry concerns, 2) that the model will be used to investigate various proposals of modulation, configuration, FEC, interleaver, and etc. (i.e. a PHY configuration), 3) that the output of investigation include at least raw performance, performance with FEC (if studied), interleaver (if studied), etc. as well as detailed latency impact (fixed delay and delay variation) and impact on EPON system scheduling, and 4) with the goal of identifying one or more acceptable system solutions that meet or are better than at least 1x10^-10 BER with a preferred goal of 1x10^-12 BER.
"Acceptable system solution" is an acceptable PHY configuration that provides acceptable EPON system performance.
My thoughts for now.
Mark
ps. I'll be about 45 minutes late into the call due to a Dr's appointment that couldn't be changed on short notice.
-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Monday, April 30, 2012 12:54 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Continuing work on EPOC objectives
Hugh,
Probably it would be also worth mentioning that there discussion on "improving" it even further to 10^-14 (?) for higher speed links (40G and 100G) but technical problems in measuring such BER values at normal operating conditions made distinction between 10^-12 and 10^-14 complex at best.
On your last point - I think this is precisely what we need to see at this meeting to close this discussion once and for all. Also, it would help to see raw BER figures, and FEC gain assumptions, because only that will give us enough information on what the effective BER at MAC service layer we can expect.
Marek
-----Original Message-----
From: Hugh Barrass (hbarrass) [mailto:hbarrass@xxxxxxxxx]
Sent: 30 April 2012 01:29
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Continuing work on EPOC objectives
Kevin,
The "tradition" of 10^-12 is like most traditions - it started at an undefinable time with undefined reasons.
The required BER of 100M Ethernet is 10^-10. For 1000BASE-X it was "improved" to 10^-12 (but not for 1000BASE-T). Later definitions have all adopted 10^-12.
From the higher layer perspective, most transport layers are designed to operate with a frame error ratio <10^-6 - so they are quite happy with a BER < 10^-10 and they aren't noticeably improved by the lower BER. It was argued that setting the BER to 10^-10 for gigabit or higher bit rates would result in observable errors that were too frequent on the interface (e.g. every 10 seconds) and that "customers" would not like that. This is a difficult assertion to prove one way or the other. Of course customers (and even system vendors) will always demand the lowest possible BER but the laws of physics are notoriously intransigent and cost increases significantly as one approaches perfection.
In short, if there is representation of a large tranche of customer demand requesting 10^-10 then that will be an acceptable objective.
Whatever the BER objective, there will be a requirement to prove that the Mean Time To False Packet Acceptance is sufficiently long (traditionally 10 billion years). A low BER can raise the risk that the CRC integrity can be compromised and therefore an errored packet could escape detection and cause havoc amongst the data.
Hugh.
-----Original Message-----
From: Noll, Kevin [mailto:kevin.noll@xxxxxxxxxxx]
Sent: Sunday, April 29, 2012 12:45 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Continuing work on EPOC objectivesŠ
I haven't seen much discussion of the objectives over the weekend. This is good because you are all supposed to be spending time away from work-related activities on the weekends. :-)
To bring up a more specific item for discussion - I'd like to hear suggestions on how to handle Objective 9.
9. PHY to have a BER better than or equal to 10-10 at the PHY service interface.
We started this objective with a BER of 10^-12 based on a misunderstanding of the expectations in 802.3. We have heard several opinions on this leading me to believe that 10^-10 is a reasonable goal.
What problems do you all see with setting the BER goal to be 10^-10?
--kan--
--
Kevin A. Noll
-----Original Message-----
From: <Noll>, Kevin Noll <kevin.noll@xxxxxxxxxxx>
Reply-To: Kevin Noll <kevin.noll@xxxxxxxxxxx>
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_EPOC] Continuing work on EPOC objectivesŠ
SG members,
I will be unable to attend the conference call tomorrow, so we will likely not work on the objectives.
In order to keep the work moving along, I would like to open a dialog here on the mailing list. I've copied below the latest revision of the objectives that were adopted and those that still need work. Please comment and/or suggest changes to the "TO BE CONSIDERED" set.
ADOPTED IN MARCH
1. Specify a PHY to support subscriber access networks using the EPON protocol and operating on point-to-multipoint RF distribution plants comprised of all-coaxial cable or hybrid fiber/coaxial media.
2. Maintain compatibility with 1G-EPON and 10G-EPON, as currently defined in IEEE Std. 802.3 with minimal augmentation to MPCP and/or OAM if needed to support the new PHY.
5. PHY to support symmetric and asymmetric data rate operation.
6. PHY to support independent configuration of upstream and downstream transmission operating parameters.
7. PHY to operate in the cable spectrum assigned for its operation without causing harmful interference to any signals or services carried in the remainder of the cable spectrum.
TO BE CONSIDERED
4. Provide at least one physical layer specification that is capable of operating at :
A baseline data rate of at least 1 Gbps at the PHY service interface when transmitting in 120 MHz, or less, of assigned spectrum under baseline plant conditions; data rates lower than the baseline rate when transmitting in less than
120 MHz of assigned spectrum or when plant conditions prevent a higher data rate; data rates higher than the baseline rate and up to 10 Gbps when transmitting in more than 120 MHz of assigned spectrum or when plant conditions support a higher data rate;
9. PHY to have a BER better than or equal to 10-10 at the PHY service interface.
--kan--
Kevin A. Noll
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1