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