[EFM] "Pause Doesn't Work" - Why
In working with Ethernet for over 20 years, the one functionality that is
most severely vendor dependant is 802.3x "Flow Control". Perhaps it is
partly the politics of the 802.3WG. Perhaps the politics of IETF pushing
their flow and rate adaptation to the exclusion of other layer or types is
partly to blame. In some cases it marketing decisions on the part of
vendors that cause them to improperly implement 802.3x in their interfaces
and systems. For those vendors that are purely Ethernet and expect
themselves to do things right, 802.3x Flow Control works to a level and
quality that is at first surprising to their customers. If you want more
information about my experiences with vendors and their implementations of
802.3x, continue to read.
I had a set of switches that were OEM'ed from the UK that had implemented
802.3x in a way that worked excellently. We got those "boxes" early on in
our work on testing optical switching of GbE and early Ethernet Over SONET
(EOS) functionality. The functionality, performance, and data reliability
enhancements were provided by 802.3x were a real surprise to
us. Unfortunately, the same vendor's equipment that was manufactured in
the US did not have an 802.3x implementation that worked, even though their
marketing indicated that it did.
I had a transmission vendor that prototyped a variance of X.86 in their
transmission nodes that implemented a properly working 802.x Flow Control.
(When I asked the engineer that did the interface about it, he said that it
was part of the GbE chip set that they had obtained, so he just made the
"hooks" into the rest of the interface according to specifications. He
seemed surprised that I might think it was not supposed to work.) When
that same vendor rolled out their general release version of EOS, it was
based on G.gfp, and 802.3x Flow Control no longer worked
properly. Ironically, the overall performance of their EOS interfaces
degraded as well with the implementation of G.gfp. In over two years of
working on the performance/reliability problems, the last time that I had
information on it, they had still not resolved any of them.
There are two transmission equipment vendors that have implemented variants
of X.86 as their EOS offering. In the transmission nodes from both of
these, 802.3x Flow Control works properly. One vendor has major deployment
in Japan and is part of that country's "Fixed Line" Ethernet services. The
other vendor has major deployments in the large companies in the US and
Europe providing Ethernet Private Line data transmission capability over
the existing SONET and SDH service provider "circuits". In both cases,
their customer's make good use of 802.3x Active Flow control.
Ironically, the data switches from one of the X.86 transmission vendors has
implemented EOS with G.gfp and uses a "RED" type of rate adaptation. Even
though support for 802.3x is indicated on their marketing literature, it
does not work properly. I asked one of their marketing engineers about it
and got the comment to the effect that they were wanting to sell their
customer on their IETF based implementations not their 802.3 based
implementations. To them the term "Ethernet" was a marketing tool
only. They did not expect things like 802.3x to work properly and thus
they did not.
Two other major "Ethernet" vendors started out with only support for 802.3x
switching. In their early boxes 802.3x worked with some specific
limitations. As they added IETF routing capability in an attempt to cash
in on the "bubble", they implemented IETF versions of rate/flow adaptation
and degraded the 802.3x capability that had been there. In asking their
marketing support engineers about that, one of them indicated that they
considered the IETF capability to be more of a marketing advantage than
having good implementation of all of the 802.3 standards. He was told that
his management did not believe that 802.3x was supposed to "work" and thus
they did put any effort into it.
To sum it up, the functionality of 802.3x Flow Control, "Pause" as we have
been discussing it, is more of a self fulfilling prophecy of the politics
of the 802.3WG and IETF. Where it works, it does so against the "correct"
view of its use. From the stories that I have been told about the
development of the standard, many vendors were not enthusiastic. Most
vendors, apparently, had very low expectations and put very little effort
into making implementations of 802.3x that were usable by their
customers. In an effort to cash in on the bubble, many vendors have put a
lot of effort and "marketing" into support for the IETF forms of rate/flow
adaptation, all of which degrade performance and data reliability.
Former Sr Engineer as MCI/WorldCom working on IP over DWDM, Optical
Switched Networking, and Ethernet Private Line services.