Re: Rat hole: Revisting the compromises - transmission bandwidth of the WAN compatible PHY
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