Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: AW: [EFM] PON Optics Telephone Conference, December 5th




Thanks for the comments Roy.
-Kent

> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx] 
> Sent: Friday, December 13, 2002 8:24 AM
> To: Mccammon, Kent G.; 'Richard Brand'
> Cc: Mccammon, Kent G.; stds-802-3-efm@ieee.org
> Subject: RE: AW: [EFM] PON Optics Telephone Conference, December 5th
> 
> 
> Kent,
> 
> Until 802.3ah, Ethernet does not induce any jitter in the 
> transmission of 
> application data.  I spent over a year in the lab looking at 
> this.  The 
> 802.3 stack, up until now was a pure streaming environment 
> without any 
> store and forward queues.
> 
> This may sound like a bit of heresy as I am the original host 
> master for 
> MCI.  The worst culprit in inducing jitter in the transmission of 
> application data in today's environment is Internet Protocol. 
>  This occurs 
> across all vendor lines using IP stack code from multiple vendors.  I 
> believe that it is because the IP stack is fairly "deep" and 
> there are 
> several locations in the stack where some form of "store and 
> forward" is 
> required.  (Even forward looking code does not solve this problem.)
> 
> You can have your lab people verify this.  Testing applications in 
> non-routing environments will change the level of jitter that 
> introduced in 
> the communications infrastructure.  This effect of streaming 
> switching was 
> one of the main reasons that the "legacy free service 
> providers" were able 
> to deliver packet voice that had better clarity and sound 
> quality than the 
> local RBOC.  Testing using a non-routing stack such as 
> NetBEUI will change 
> the amount of jitter that is introduced at the end systems 
> supporting the 
> applications.  Interactive video becomes very "tight" in a 
> non-IP environment.
> 
> How 802.3ah will perform relative to the "jitter" issue has yet to be 
> seen.  It is most likely that the data stability that LAN 
> people are used 
> to will no longer be there.
> 
> Thank you,
> Roy Bynum
> 
> 
> 
> At 09:30 PM 12/8/2002 -0800, Mccammon, Kent G. wrote:
> 
> 
> >Richard,
> >Controlling jitter over an Ethernet network is a project that we 
> >support in other forums than 802.3ah.  My comment and question was  
> >attempting to gather more information in the debate over common PMD 
> >timing specifications. If the Options A-D in the debate of 
> PON timing 
> >have different possible services enabled, I think that is a fair 
> >question to ask on this exploder. I don't  support multiple 
> Gigabit PON 
> >timing specifications each one for a only subset of 
> potential service 
> >applications. Thanks, -Kent
> >
> > > -----Original Message-----
> > > From: Richard Brand [mailto:rbrand@xxxxxxxxxxxxxxxxxx]
> > > Sent: Friday, December 06, 2002 12:34 PM
> > > To: Roy Bynum
> > > Cc: kmccammon@tri.sbc.com; stds-802-3-efm@ieee.org
> > > Subject: Re: AW: [EFM] PON Optics Telephone Conference, 
> December 5th
> > >
> > >
> > > Roy:
> > > So here we go.  I agree with everything you state except 
> that Kent 
> > > did not ask about "Leased Circuit Private Line services " or 
> > > "Ethernet Private Line" but about T1 services over a draft 802.3 
> > > P2MP network. In addition Ethernet private line or leased line 
> > > services are just as much out of scope for 802.3 as is 
> TDM based T1 
> > > services. That's why we have taken on that work in the MEF with a 
> > > close liaison to the ITU work to which you make reference.  That 
> > > also gets into encapsulation, but that is surely out of scope for 
> > > .3. Therefore, I am correct in saying that your message did not
> > > answer his question.  I do believe Arial's note makes an
> > > attempt to address the efficiency question, but I
> > > believe that the potential for added jitter is real.   It is
> > > however, out of scope
> > > for .3.  Kent, any comments?
> > > Regards,
> > > Richard
> > >
> > >
> > > Roy Bynum wrote:
> > >
> > > > Richard,
> > > >
> > > > You are incorrect. 802.3 in and of itself can NOT be used
> > > to provide
> > > > Leased Circuit Private Line services. I am the author of
> > > the term and
> > > > definition of "Ethernet Private Line" services. Ethernet
> > > Private Line
> > > > is based on SONET/SDH, not 802.3
> > > >
> > > > ITU standards for leased circuit private line services 
> > > > specifically states that the customer of the leased circuit has 
> > > > exclusive use of the circuit facility. This is in contrast to 
> > > > "packet"
> > > services that do
> > > > emulation via a "virtual" circuit. Since 802.3ah PON does
> > > not provides
> > > > virtual circuit emulation via the frame "header", called a
> > > "preamble"
> > > > by 802.3 and not any type of physical or time based facilities 
> > > > segregation, it falls under the category of a
> > > "packet/frame" service
> > > > technology, not a leased circuit service technology.
> > > >
> > > > The existing ITU standards already provides for 
> permanent virtual 
> > > > circuit emulation at fixed bandwidths over packet/cell
> > > based services.
> > > > These can be at T1 or any other fixed bandwidth.  The ITU 
> > > > standards makes a specific distinction between the "leased 
> > > > circuit"
> > > services and
> > > > the emulated circuit services over packet/cell/frame transport 
> > > > protocols.
> > > >
> > > > I didn't write the ITU standards. I just spent the last 
> year that 
> > > > I was at Worldcom researching the specifics of defined 
> standards 
> > > > for different types of data communications services.
> > > >
> > > > 802.3 in and of itself does not provide leased circuit private 
> > > > line services. The fact that a single customer using 
> 802.3 can be 
> > > > provisioned as the only customer on a "dark" fiber, 
> makes the dark 
> > > > fiber, a leased circuit private line service, not the 
> 802.3. This 
> > > > format would also hold for 802.3ah copper facilities that
> > > are used by
> > > > a single customer.
> > > >
> > > > The service "Ethernet Private Line" is not based on an
> > > 802.3 standard,
> > > > other than it provides a "mapping" for Ethernet frames. The
> > > ITU x.86
> > > > "Ethernet over LAPS" provides for "mapping" of Ethernet frames 
> > > > into SONET/SDH by replacing the IFG/Preamble with LAPS, a HDLC
> > > derivative
> > > > and then using TDM nature of SONET/SDH to provision the
> > > service as a
> > > > standard leased circuit facility.  This would also hold 
> for g.GFP.
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > At 02:40 PM 12/5/2002 -0800, Richard Brand wrote:
> > > > >Thomas:
> > > > >I would offer that Roy's note does not answer question 1
> > > and I have
> > > > >sent a note to Roy to detail.  As Kent is aware, there is
> > > an ongoing
> > > > >project in the MEF right now to specify circuit services (read 
> > > > >TDM including T1) over Ethernet including 802.3 networks. The 
> > > > >timing issue could be critical to some implementations
> > > and is one of the
> > > > >reasons I voted "no" in Kauai.  Vipal, do you want to 
> take it on? 
> > > > >Regards, Richard Brand
> > > > >
> > > > >
> > > > >
> > > > >Thomas.Murphy@xxxxxxxxxxxx wrote:
> > > > >
> > > > > > Hi Kent,
> > > > > >
> > > > > > Thanks for your input on this topic. I believe that 
> question 
> > > > > > 1) has already been addressed by Roy Bynum; there are
> > > others who are
> > > > > > in a better position to answer this than me.
> > > > > >
> > > > > > Regarding testing I see two different levels/types 
> of testing. 
> > > > > > Firstly there is module testing where different 
> response times 
> > > > > > will not present a problem (the response time is
> > > probably one of
> > > > > > the parameters that would be determined). Beyond 
> this there is 
> > > > > > then system/interoperability testing. When testing with
> > > > > 'non-intelligent'
> > > > > > equipment, the guardband between bursts would be set to the 
> > > > > > Upper-Bound values agreed upon. By guardband I mean the
> > > time delay
> > > > > > between the Tx_On signal and the time when the Rx
> > > starts examining
> > > > > > bit to determine the BER. With an intelligent system, i.e. 
> > > > > > protocol implementation with negotiated parameters, 
> > > > > > interoperability is not a problem as the optimal
> > > guardband is calculated.
> > > > > >
> > > > > > The above tests determine if one Tx communicates optically 
> > > > > > with the
> > > > > expected
> > > > > > BER
> > > > > > with another Rx. Setting the guardband equal to the upper 
> > > > > > limit determines that the timing requirements of 
> the combined
> > > link are
> > > > > > met. Direct module testing delivers the individual 
> Rx and Tx 
> > > > > > times.  Hence, I don't see a problem with testing
> > > depending on the
> > > > > > option choice for the timing parameters.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Tom
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Mccammon, Kent G. [mailto:kmccammon@xxxxxxxxxxx]
> > > Gesendet am:
> > > > > > Donnerstag, 5. Dezember 2002 02:45
> > > > > > An: Murphy Thomas (COM FO D O); stds-802-3-efm@ieee.org; 
> > > > > > Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx
> > > > > > Betreff: RE: [EFM] PON Optics Telephone Conference, 
> December 
> > > > > > 5th
> > > > > >
> > > > > > Tom,
> > > > > > Since I have a conflict with the call tomorrow and I am
> > > interested
> > > > > > in this decision, here are some questions.
> > > > > >
> > > > > > 1)Do any of the options for PON timing impact the 
> delivery of 
> > > > > > services such as toll quality voice, a T1, or multicast
> > > video? We
> > > > > > had this concern previously and the answer previously
> > > was claimed
> > > > > > to be only an efficiency hit for loose timing. Are the 
> > > > > > modeling assumptions to compare efficiency valid for TDM 
> > > > > > services or is that not a consideration in this debate to 
> > > > > > date? 2)The
> > > negotiation
> > > > > > of timing parameters rather than a tight specification have 
> > > > > > any impact on future interoperability testing?  If we ever
> > > decide to
> > > > > > test interoperability of EPON OLT and ONT, can a 
> lab testing 
> > > > > > system be reasonably built to test compliance to a
> > > specification
> > > > > > for OLT/ONT timing for the various options under 
> debate? 3)Do 
> > > > > > operating temperature swings have an impact on timing
> > > options. Is
> > > > > their
> > > > > > reason to add extra margin or extra negotiation 
> time of timing 
> > > > > > parameters due to temperature variations? What about
> > > cold start in
> > > > > > cold temperatures, that was an issue for power 
> levels, does it 
> > > > > > also impact the electronics of the PMD?
> > > > > >
> > > > > > Comment: As an advocate of PON technologies I echo 
> my earlier 
> > > > > > comments
> > > > > about
> > > > > > striving for common PON PMD to get the volume started in 
> > > > > > today's
> > > > > economy.  I
> > > > > > am optimistic a compromise can be found in January. Thanks, 
> > > > > > -Kent
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Thomas.Murphy@xxxxxxxxxxxx 
> > > > > > > [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> > > > > > > Sent: Wednesday, December 04, 2002 10:12 AM
> > > > > > > To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org;
> > > wdiab@xxxxxxxxx
> > > > > > > Subject: [EFM] PON Optics Telephone Conference, 
> December 5th
> > > > > > >
> > > > > > >
> > > > > > > Hello Again,
> > > > > > >
> > > > > > > Attacted two possible approaches to this discussion
> > > forming two
> > > > > > > decision trees. Glen and I worked on these I I 
> did not have 
> > > > > > > a chance to co-ordinate with him and refine to 
> one slide.  
> > > > > > > The first slide is mine and I would like to start here as
> > > it allows
> > > > > > > us to generate values without having to make
> > > decisions. When the
> > > > > > > values are agreed upon, we can work towards the 
> decision and 
> > > > > > > perhaps this is simpler with the values we have.
> > > > > > >
> > > > > > > If this does not work, we can try the seconf 
> slide, Glen's 
> > > > > > > approach, which is a more top-down attack.
> > > > > > >
> > > > > > > Talk to you tomorrow
> > > > > > >
> > > > > > > Tom
> > > > > > >
> > > > > > >  <<PON Timing Decision Tree.ppt>>
> > > > > > >
> > > > > > > Hello All,
> > > > > > >
> > > > > > > Items to Be Covered
> > > > > > >
> > > > > > > 1)  Determine the exact meaning of the terms "Fixed
> > > Value" and
> > > > > > > 'Upper Bound" in terms
> > > > > > >     of their use for PMD timing parameters.
> > > > > > >
> > > > > > > 2)  Try assign placeholder values for all of the options
> > > > > > >
> > > > > > > 3)  Are these values fixed or bounded for the
> > > different options.
> > > > > > >
> > > > > > > 4)  Other items
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Tom
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > >
>