Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

reserve a seat
back to overview

On the Lossiness of TCP

When someone tells you that “TCP is a lossy protocol” during a job interview, don’t throw him out immediately – he was just trusting the Internet a bit too much (click to enlarge).

Everyone has a bad hair day, and it really doesn’t matter who published that text… but if you’re publishing technical information, at least try to do no harm.

Let’s do a step-by-step walk through that bit of wisdom:

The foundation of TCP/IP design is that the network is unreliable and packets will be lost.


In fact, the TCP protocol demands this feature to determine the maximum possible transfer rate. 

Wrong. TCP reacts to packet drops and delays (increased round-trip-time; RTT). It turns out it’s better to delay packets than to drop them on low-speed links with a small number of TCP sessions, and it’s really easy to reproduce the measurement Jeremy Stretch did a long time ago.

We could go into a lengthy discussion on when it’s time to start dropping the packets instead of buffering them (see also Bufferbloat), and how TCP ECN could be used to alleviate congestion before the dropping starts, but that’s way beyond the point.

So it’s impossible to make TCP lossless, it’s designed into its operation.

You don’t have to trust me or Wikipedia, but you might trust the authors of RFC 793:

TCP provides for reliable inter-process communication between pairs of processes in host computers attached to distinct but interconnected computer communication networks.

I’d guess that reliable and lossy usually aren’t considered synonyms.

Back to the lossiness of TCP… seems it has some impact on QoS:

This is why Quality of Service never works. TCP will drop packets in almost every systems because there is less bandwidth in the network than the endpoints can transmit.

Another sound bite for a job interview, right? ;) It’s not totally wrong:

However, if:

  • you can’t throw bandwidth at the problem,
  • you can separate your traffic into few coarse classes, and
  • you realize QoS is always a zero-sum game

… then you can use QoS mechanisms like policing, shaping, queuing or dropping to improve the service offered to some traffic at the cost of other traffic. Just keep in mind that you’re trading link cost for increased operational complexity (and associated costs).


  1. Very nice response. When I read the original article I was scratching my head as well. I guess the original author chose a wrong word - lossy.
    Maybe his intention was to describe the fact that almost any normal TCP stream has certain amount of drops and retransmisions. We all have been on many troubleshooting calls, trying to explain this little fact to everybody...

    P.s. The picture that describes the throughput is also weird, every oscilation should be smaller and smaller...

  2. It is a pretty poorly written article. i rarely see loss on a telnet or ssh sessions (not running a vpn or file transfer inside), but since most people just look at tcp sessions running large web downloads or file transfers, they see congestion caused loss as the norm i guess.

    The title of the post seems like it would be right at home in the "National Inquirer", which is a gossip rag here in the US.

  3. And just for clarity, i did NOT mean your article, I meant the one that you are responding too above.

  4. Yeah, it's poorly worded. "TCP is designed to operate on a lossy network, and uses loss as a signal to slow down" might be better.

  5. Yeah, it's poorly worded. "TCP is designed to operate on a lossy network, and uses loss as a signal to slow down" might be better.

  6. Kristijan Taskovski21 June, 2016 18:12

    Ivan being awesome as always

  7. I thought the last part - that "nobody cares" - was the biggest howler of all. What rock has the author been hiding under?

  8. Oh, just found out who wrote that. The clickbaity nature of the original no longer surprises me.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.