Ages ago when we were building networks using super-expensive 64kbps WAN links, a customer sent us a weird bug report:

Everything works fine, but we cannot transfer one particular file between two locations – the file transfer stalls and eventually times out. At the same time, we’re seeing increased number of CRC errors on the WAN link.

My chat with the engineer handling the ticket went along these lines:

Me: What kind of modems are they using?
Him: One of those weird baseband modems¹ running at 128 or 256 kbps
Me: Try enabling link compression²

A few hours later, he came back to me saying “That solved the problem. How did you know?”

WTF?

At that time, I had a few bad experiences with the baseband modems pushing the performance envelope way past the breaking point, and suspected that it might be a clock synchronization issue: a long sequence of zeroes or ones would cause the receiving modem to lose synchronization with the transmitting modem’s clock. A well-designed solution should use line encoding that would allow the receiver to recover clock from any input data, but when you buy magic products, you get magic behavior.

A long sequence of ones shouldn’t be a problem on an HDLC³ link – the HDLC encoding inserts a zero after five consecutive ones to avoid end-of-frame sequence (six consecutive ones) – but there’s nothing HDLC can do about long sequences of zeroes. Link compression replaced long sequences of zeroes with some other sequence of bits. Problem solved.

Encryption would probably work equally well, as would NRZI encoding. I don’t think Cisco IOS had encryption at that time (and we’d be wasting CPU cycles without any performance gain), and you couldn’t set NRZI encoding on some serial interfaces. Using link compression made our customer happy, and their network seemingly faster.

More to Explore

Why don’t you check out How Networks Really Work webinar – you can watch numerous videos in that webinar with Free ipSpace.net Subscription.