* Intelligent vs. random packet discard
In the last newsletter, we continued a discussion of discarding voice vs. data packets. This time we’ll continue that discussion with a proposal for how data transmission could be greatly enhanced by discarding packets more intelligently.
First, a clarification from the last newsletter: Modern protocols all have a number of outstanding packets of data that are permitted. In some cases, the packets are explicitly numbered and in other cases they are implicitly numbered by using a byte-count. But regardless of the method, one may assume that there are at any point in time “n” outstanding but unacknowledged packets that may be awaiting acknowledgment. In this context, we will refer to these as packets Nos. 1 through “n”, regardless of the exact method used.
In the last newsletter, we used an example of there being five outstanding packets with an error in the first of the packets. We pointed out that for many protocols, not only is the errored packet retransmitted, but also the four packets that followed. (The exception to this is if TCP is in use and the option for “Selective Acknowledgment” has been negotiated at the time that the session was established. More on this topic in a later newsletter.) That’s bad enough.
But the bigger problem is that most equipment (we believe) starts discarding data randomly once there is a need to discard. For instance, assume that five packets need to be discarded, and there are five streams (streams “a” through “e”) of equal priority. Once the first packet from data stream “a” is discarded, it is much better to continue discarding data from that stream than to be “fair” to all streams and discard one packet from each.
If all of the packets are discarded from the same stream, then only data from that stream is impacted – whether selective acknowledgment is used or not. If you discard one packet from each of the five streams, then you impact data on all five streams.
And if all the above weren’t problem enough, there’s yet another issue. If the traffic is TCP and there is a dropped packet, in addition to the retransmission delay – with or without selective acknowledgment – phenomenon, TCP typically reduces the window size. Hence, it is really “retransmit slowly” until I can trust you to not drop any more packets.
We’ll look forward to hearing (briefly, please!) from the manufacturers as to how much progress they are making in implementing these intelligent discard possibilities and the impact that they are seeing on network throughput.
