Re: Rat hole: Revisting the compromises - transmissionbandwidth of the WAN compatible PHY
Rich,
I knew that this was too good to last. No by leaving OAM&P just like it
is, means that I will not be voting AGAINST LSS.
Roy
At 10:56 PM 7/18/00 -0700, Rich Taborek wrote:
>Roy,
>
>Wow! Is this the second agreement in a row between us? I agree with
>leaving LSS
>just like it is. It sounds like you'll be voting for LSS next time around.
>
>Best Regards,
>Rich
>
>--
>
>Roy Bynum wrote:
> >
> > Rich,
> >
> > I agree very much. Revisting all of the "stuff" is just so much of a "rat
> > hole". That is the reason that I believe that it is best to just leave LSS
> > alone.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 02:08 PM 7/18/00 -0700, Rich Taborek wrote:
> >
> > >Roy,
> > >
> > >I realize that this is a rat hole you entered, off the thread of LSS
> for the
> > >LAN, then LSS OAM&P, then why the WAN PHY OAM&P is better than LSS
> OAM&P, then
> > >the bandwidth difference of Ethernet LAN vs. WAN PHY... but I'll
> indulge you
> > >anyway.
> > >
> > >You point out below that inefficient PCS coding is responsible for the
> first,
> > >second and third-order effects on bandwidth of the WAN PHY. This is
> > >mathematically impossible and incorrect. Getting back to the original
> thread,
> > >LSS support of OAM&P is FREE in terms of available bandwidth and is a ZERO
> > >overhead protocol. To the contrary, WAN PHY OAM&P itself costs 5.2% in
> > >terms of overhead. Therefore, the WAN PHY is a significantly inferior
> solution
> > >to providing OAM&P functionality for Ethernet link for all applications
> > >including LAN, MAN and WAN. Note that the WAN PHY PCS overhead is only
> 3.125%.
> > >Which overhead do you consider to be first order again?
> > >
> > >The Length/HEC proposal for the WAN PHY is dead. It was not even
> mentioned for
> > >consideration for the baseline P802.3ae proposals. For many, many
> reasons, the
> > >WIS proposal is far superior to Length/HEC and achieved 96.3% support from
> > >IEEE 802.3 voters in La Jolla. Get over it.
> > >
> > >I won't indulge any other tangents such as XAUI and the 100.00000%
> IEEE voter
> > >support for 8B/10B block encoding in this thread as it is a 5th order
> tangent
> > >and I'm stopping at 3 :-)
> > >
> > >Best Regards,
> > >Rich
> > >
> > >--
> > >
> > >Roy Bynum wrote:
> > > >
> > > > Rich,
> > > >
> > > > Not to revisit too many of the issues with the compromises that have
> > > > already been made all in the same message thread, I will respond to
> your
> > > > response one issue at time. This thread is to set the story
> straight about
> > > > the bandwidth hit on the WAN compatible PHY.
> > > >
> > > > You said:
> > > > "The first order bandwidth hit to the WAN PHY is the fault of SONET
> > > > framing. The second order hit is due to the block coding PCS.
> However, it
> > > > is the block coding PCS that allows the direct mapping of Ethernet
> to SONET
> > > > at the physical layer. The current "cell tax" of ATM is a much worse
> > > > bandwidth hit than 64B/66B for Packet over SONET.
> > > >
> > > > Note that the LAN PHY doesn't seem to have any problem with the
> same PCS,
> > > > and is capable of supporting a full 10 Gbps data rate, transporting
> greater
> > > > than 7% more data than SONET. This provides customers interested in
> > > > connecting their LANs over typical MAN/WAN distances with a cost
> effective,
> > > > straightforward and significantly higher bandwidth transport... and
> a clear
> > > > decision point."
> > > >
> > > > Actually you are wrong about the order of the bandwidth hits to the WAN
> > > > compatible PHY. A first order bandwidth hit was taken by the WAN
> > > > compatible PHY because of the fixed SONET signalling rate. The SONET
> > > > signalling rate that was proposed for the WAN compatible PHY did
> not allow
> > > > it to adjust to higher signalling rates to compensate for inefficient
> > > > coding schemes. The second order bandwidth hit was the reduced
> function
> > > > SONET sync frame overhead that removed additional bandwidth. The third
> > > > order hit to the WAN compatible PHY was when a compromise forced an
> > > > inefficient coding scheme on the data stream, based on block coding,
> > > > similar to fiber channel.
> > > >
> > > > The original proposal for the WAN compatible PHY used HEC frames to
> replace
> > > > the IPG and preamble and then one for one scrambling. This was a very
> > > > efficient coding scheme. The original proposal did not introduce
> any third
> > > > order bandwidth hits. Because the original proposal replace the
> IPG with
> > > > distinct frames, the number of HEC frames between the data frames
> could be
> > > > reduced and thus compensate for the first and second order
> bandwidth hits.
> > > > A similar mechanism will need to be employed to remove IPG idle
> bytes in
> > > > the existing compromise in order to compensate for the IPG
> expansion of the
> > > > open loop control of the transfer rate. In fact, some of the third
> order
> > > > bandwidth loss can be compensated by compressing the IPG before it gets
> > > > block encoded.
> > > >
> > > > As for the LAN PHY not having bandwidth hits, it is mater of
> > > > prospective. The data transfer rate only remains constant for the
> LAN PHY
> > > > because of a first order bandwidth hit on the signalling rate. In
> order to
> > > > maintain the transfer rate using a block coding scheme in the PCS, the
> > > > signalling rate must be increased. That is the reason that a
> scheme that
> > > > is more efficient than the original 8b/10b was introduced. Is a
> mater of
> > > > fact, the original block coding is so inefficient that it is only
> used for
> > > > multi-wavelength or multi-fiber PMD proposals. ( I admire the
> subterfuge
> > > > by which that fiber channel has been maintained as a prominent coding
> > > > scheme in P802.3ae. My hat is off to you. :-) )
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > (I will take up other threads at a later date.)
> > > >
> > > > At 01:23 AM 7/18/00 -0700, Rich Taborek wrote:
> > > >
> > > > >Roy,
> > > > >
> > > > >As you might expect, I just love a good dog fight :-)
> > > > >
> > > > >Break Link and Remote Fault are bastions of Ethernet link
> management and
> > > > >generally all that is needed to manage an Ethernet LAN link. OAM&P is
> > > > >associated with SONET/SDH, provides Break Link and Remote Fault
> support
> > > > >along with a myriad of functions and features, most of which are not
> > > > > applicable to Ethernet.
> > > > >
> > > > >Besides, LSS is capable of supporting both Break Link and Remote Fault
> > > for LAN
> > > > >PHY links used in LAN environments as well as OAM&P for LAN PHY links
> > > used in
> > > > >MAN/WAN environments.
> > > > >
> > > > >Please see my additional comments below:
> > > > >
> > > > >Roy Bynum wrote:
> > > > > >
> > > > > > Ben,
> > > > > >
> > > > > > I may start a dog fight with this comment but here goes.
> > > > > >
> > > > > > I question why there needs to be so much effort to insert "break
> > > link and
> > > > > > remote fault" when OAM&P functionality was the primary purpose
> > > behind the
> > > > > > WAN compatible PHY. There was a lot of argument about how to best
> > > go about
> > > > > > providing that OAM&P. There was a MAJOR compromise to split the
> > > PAR into
> > > > > > two distinct PHY logics, one with OAM&P and one without.
> > > > >
> > > > >There was never any PAR split. The HSSG merely added a WAN PHY
> > > objective to
> > > > >provide direct mapping from 10 GbE to OC-192c/SDH VC-4-64c
> > > > >
> > > > > > Now I am seeing an attempt to put OAM&P functionality into the PHY
> > > logic
> > > > > > that originally specifically excluded OAM&P. I voted against LSS
> > > because
> > > > > > the additional complexity in a LAN is not needed. If an
> implementation
> > > > > > architecture requires OAM&P, the WAN compatible PHY is available.
> > > > >
> > > > >The WAN PHY is deemed by some to be far more complex and costly than
> > > > >required to connect Ethernet LANs together without going through SONET
> > > > >equipment. Granted, these are greenfield applications. However,
> there are
> > > > >customers for Ethernet LAN PHY links beyond the LAN. The WAN PHY is
> > > neither
> > > > >intended as an Ethernet LAN link nor a SONET replacement. Its sole
> purpose
> > > > >is to facilitate the attachment of 10 Gbps Ethernet equipment
> directly to
> > > > >SONET.
> > > > >
> > > > > > There should not be any optical distinctions between the LAN PHY
> > > without
> > > > > > OAM&P and the WAN compatible PHY with OAM&P.
> > > > >
> > > > >I'm not sure what this statement implies. If it implies what I
> think it
> > > > >implies, the optics will be similar if not the same. Optical specs are
> > > > >likely to be different due to significant differences in coding
> schemes
> > > > >and data rates.
> > > > >
> > > > > > Given the major transfer bandwidth hit that was forced on the WAN
> > > > > > compatible PHY by a block coding PCS, OAM&P functionality is
> one of the
> > > > > > distinctions that provides customers with a clear decision point.
> > > > >
> > > > >The first order bandwidth hit to the WAN PHY is the fault of SONET
> > > > >framing. The second order hit is due to the block coding PCS. However,
> > > it is
> > > > >the block coding PCS that allows the direct mapping of Ethernet to
> > > SONET at
> > > > >the physical layer. The current "cell tax" of ATM is a much worse
> > > bandwidth
> > > > >hit than 64B/66B for Packet over SONET.
> > > > >
> > > > >Note that the LAN PHY doesn't seem to have any problem with the
> same PCS,
> > > > >and is capable of supporting a full 10 Gbps data rate, transporting
> > > greater
> > > > >than 7% more data than SONET. This provides customers interested in
> > > connecting
> > > > >their LANs over typical MAN/WAN distances with a cost effective,
> > > > >straightforward and significantly higher bandwidth transport... and a
> > > clear
> > > > >decision point.
> > > > >
> > > > > > I would recommend that the group take the failure of the group to
> > > > > > provide 75% support as an indication that this should be dropped
> > > and energy
> > > > > > spent on other things.
> > > > >
> > > > >To me this sounds like more of the same kind of FUD which resulted
> in an
> > > > >abstention vote 34% higher than the opposition vote in light of a more
> > > > >than 63% yes vote. Using the same logic, do you also recommend the
> > > Task Force
> > > > >abandon multimode fiber cable plants?
> > > > >
> > > > > > Thank you,
> > > > > > Roy Bynum
> > > > > > A customer
> > > > >
> > > > >Best Regards,
> > > > >Rich
> > > > >SPCA
> > >
> > >-------------------------------------------------------
> > >Richard Taborek Sr. Phone: 408-845-6102
> > >Chief Technology Officer Cell: 408-832-3957
> > >nSerial Corporation Fax: 408-845-6114
> > >2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> > >Santa Clara, CA 95054 http://www.nSerial.com
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
>Santa Clara, CA 95054 http://www.nSerial.com