It’s not true that voice should always have priority over data

Opinion
Jun 22, 20062 mins

* Intelligent vs. random packet discard

Last time, we continued a discussion of what happens in an MPLS network if defined traffic levels are exceeded so that some packets need to be dropped. In particular, we stated that there is a belief that – to a certain extent – it is better to drop a few voice packets than to deliver it late. The reason behind this phenomenon is that modern packet voice algorithms are designed with the assumption that some packets will be dropped. In fact, the fact that “never is better than late” led to the usage of UDP (user datagram protocol) for the transport of voice traffic. (Of course, TCP is preferred for the voice control because of the need for assured delivery.)

But this also leads to an interesting question. Over the years, we’ve become almost insanely paranoid about voice quality and dropped packets. The obsessive assumption has been that voice ALWAYS should have priority over data. And we’re going to assert that this simply is not true. Why?

Data – essentially without exception – has a way to recover from lost packets. Today, this is typically accomplished via TCP. However, until we have intelligent discard of packets, dropping data packets can wreak havoc on performance. In most cases, the protocol is a “go-back-n” protocol. For instance, if you have an outstanding window size of eight packets, five packets are unacknowledged, and the first of the five packets is discarded, then that packet AND the four following packets must be retransmitted. Further, if the discarded packets are from separate sessions, then the effect is multiplied.

The net effect is that dropping a few voice packets probably will have no impact on network performance. However, dropping data packets could cause a flood of retransmissions.

So there really are two independent actions taking place here. On the one hand, voice packets need to have the highest priority and go to the front of the queue for minimizing delay. But if there is no room at the front of the queue, then robbing bandwidth from data applications could be counterproductive.

Next time we’ll look at an even better way of prioritizing data.

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.

More from this author