Ethernet Connector

I have spent most of my career in telecommunications helping people switch to Ethernet transport to provide Internet and voice services to their subscribers. All along the way we extol the virtues of Ethernet based systems and transport over the previous generation of SONET transport. I know Ethernet like the back of my hand at this point which is why I am not afraid to say it, Ethernet sucks!

I’m pretty sure Winston Churchill said something to the effect of:

Ethernet is the worst form of transport, except for all of the others

Here is the dirty secret, Ethernet transport is really only better in two ways from comparable high capacity transport, and is worse in pretty much all of the others. I’ll save the good stuff for last of course so without further adoo, reason 1 Ethernet sucks is…

Ethernet Error Reporting Sucks

Error in Bit Stream

If you are in Enterprise networking or otherwise never touch transport networks, you might not realize how elegant and useful the SONET approach to networking is. It does seem overly complex and complicated with all sorts of weird terms. I am pretty sure most people don’t even know what the acronyms mean and don’t understand the errors either. However, SONET was designed to be reliable and informative all the way down to Layer 1. There are framing constructs all the way down the hierarchy and they all carry useful data about errors.

Imagine you log into a SONET transport node and turn a port on facing another node. How do you tell if the link is good and taking errors? Well it will tell you of course! SONET has Bit Error Rate (BER) reporting built right into the framing protocol, and since its synchronous (always on and sending even empty frames) you can always tell what the error rate is on a specific link even if the link is carrying no traffic. Contrast that with Ethernet where with an idle link you won’t usually be able to learn a thing about the quality. If you are lucky you might get an optical power reading from the optical module, but even that functionality is rare.

RFC2544 Ethernet Test Set

The Ethernet testing conundrum has led to wide use of RFC2544 traffic generators and test hardware to put enough traffic on the link to see if it even works. What that means is to test a 10 Gbps Ethernet link you need an expensive 10 Gbps Ethernet test unit and some patience. Even then, all you know for sure is that the link worked when you tested it and have very little information about quality over time as temperature changes, or components age.

Now I do understand that the Ethernet frame includes a checksum to identify garbled frames so reporting does exist. The drawback is that without live traffic on the link above a certain threshold, you can’t guarantee that the link is error free. If you work with long distance Ethernet regularly this is of course not news to you. On the other hand it goes to show why SONET or OTN where synchronous framing is used is so great for long haul transport versus standard Ethernet.

Conclusion

By the way, I am not actually saying that we should switch everything back to SONET and give up on Ethernet. My point here is that often Ethernet is used for long haul transport networks without this functional difference taken into account. By all means, keep using Ethernet, you can’t get your routers or access equipment to speak anything else anyways. On the other hand, anytime you can encapsulate your Ethernet in an OTN transport with error reporting and FEC do so. Ethernet is great at transporting data, but definitely lacking in telemetry.

I do have another few reasons why Ethernet transport sucks, so hopefully I can write them up soon and share as well.