Re: Rat hole: Revisting the compromises - transmissionbandwidth of theWAN compatible PHY
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